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I. INTRODUCTION 
A. MOTIVATION 
During the past twenty years database systems have been 
desiqned and implemented using what we refer to as 
the traditional approach. The firstystep Tee ciesc. £1 Ones 
approach involves enoecsing a datagmede!. Seamemdeve caca 
models include the relational data model, the hierarchical 


data model, the network data model 7 the chit yeaa tion oii 


- 


data model, or the attribute-based data model to name a +en. 
The second step speei ties aedel Seas] cme ese tee ea re. 
SQL or QUEL for the relational data model, or Daplex ter the 
entity-relationship data model. 


A number of database systems have been developed using 


this methodolosy. Fog example, there is 2B Ss 
Information Management System SIMS) Since the sixties, 
which supports the hierarchical data model and the 


hierarchical-model-based data language, Data Language iI 
( Die sperry Univac has introduced the DMS-1194 in the 
early seventies, which supports the network data model and 
the network—-model-based data language, CODASYL Data 
Manipulation Language (CODASYL-DML). Snd more recently, 


there has been IBM’s introduction of the SOL/Data System 


which supports the relational model and the relational- 
madel—based data language, Structured English Suey 
Pencwane (SQL). The result of this traditional approach 
to database system development is a homogeneous database 
system that restricts the user to a single data model and a 
specific model-based data language. 

An unconventional approach Pi odiatabase system 
development, referred to as the? Multi-lingual’ database 
system (MLDS) CRef. 1], alleviates: the aforementioned 
restriction. This new system affords the user the ability 
to access and manage a large collection of databases vila 
several data models and their corresponding data languages. 
The design goals of MLDS involve developing a system 
that 1S accessible Via arelational/S@L interface, an 
hierarchical/DL/I interface, a network/CODASYL 
interface, and an entity-relationship/Daplex interface. 


There is a number of advantages in developing such a 


system. Ferhaps the most practical of these involves the 
reusability of database transactions developed on an 
existing database system. In MLDS, there is no need 
for the user to convert a transaction from one data 


language to another data language. The MLDS permits the 
running of database transactions written in different data 
languages. Hence, the user does not have to perform 
either a manual or automated translation of an existing 


transaction in order to execute the transaction in MLDS. 


= 


ee 


The MLDS provides the same results even if the data language 


of the transaction 1S originated at a different database 


system. 

aa second advantage deals with the economy and 
effectiveness of hardware upgrade. Frequently, the 
hardware supporting the database system is eee 
because of technological advancements or system 
demand. With the traditional aproach, this “type of 


hardware upgrade has to be provided for all of the different 
database systems in use, so that all of the users can 
experience system performance improvements. ‘This is not 
the case in MLDS, where only the upgrade of a single 
system 1s necessary. In a MLDS, the benefits of a hardware 
upgrade are uniformly distributed across all users, despite 
their use of different models and data languages. 


Thirdly, a multi-lingual database system allows users 


to explore the desirable features of the different data 
models and then use these to better support their 
applications. This 1s possible because MLDS supports a 


Variety of databases structured in any of the well-known 
data models. 

It is apparent that there exists ample motivation to 
develop a multi-lingual database system with many data 
model/data language interfaces. In this thesis, we are 
developing a relational/S@L language interface for the MLDS. 


We are extending the work of Macy CRef. 2] and fFollins 
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CRef. 351, who have showed the feasibility of this particular 


interface in a MLDS. 


Be. THE MULTI-LINGUAL DATABASE SYSTEM 

A detailed discussion of each of the components of a 
MLDS 15 provided in subsequent chapters. In this section we 
provide an overview of the organization of a MLDS. This 
can assist the reader in understanding how the 


: ® 
different components of the MLDS are related. 


~~ 


Figure i shows the system structure of a MG ede 
lingual database system. The user interacts with the 
system through the language interface layer (LIL) using a 
chosen user data model (UDM) to issue transactions written 
in a corresponding model-based user data 
The a ee the user transactions ao} the kernel 


mapping system (KMS). The KMS performs one ot two 


sossible tasks. First, the KMS transtorms a UDM-based 


database definition to a database definition of the kernel 
is to be created. When the user specifies that a UDL 
transaction is to be executed, the KMS translates the UDL 
transaction to a transaction in the kernel data language 
fae. “ea the first task, the EMS forwards the EDM data 
fem2tren to the kernel coentroller (KOC). The KC, in turn, 


sends the KDM database definition to the kernel database 


system CDS) < When the KDS is finished with orocessing 


Y] 





mel gure jc. 


the KDM database 


then notifies 


definition has been processed and that the 


database 


sends the EDL transactions to the EEC. 


receives the 
EDS for 


results in 


reformats 


then displays the results in the correct UDM 


ae 
The four 


collectively 


the 


records may begin. In 


kK DL 
execution. 


KDM 


the results from KDM form to UDM form. 


modules, 


kNOWN 


UDM — : User Data Model 

UDL : User Data Language 

LIL . Language Interface Layer 
KMS : Kerne} Mapping System 
ee : Kernel Controllers 

KFS : Kernel! Formatting Svstem 
RDM : KRerne! Data Model’, 
aieae : Kernel Data Language 
KDS — : Kernel Database System 


The Multi-Lingual Database System. 


definition, it informs the KC. 


user via the LIL that 


loading of 


the second task, the 


When the 


transactions, 1t forwards them to 


Upon completion, the KDS- sends 


form back to the KC. The KC routes 


The 


The 
via 


form 


LIL, KMS, KC, and KFS, 


as the lanquage interface. 
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The KC 


the database 


the 


KMS 


EC 


the 


the 


the 


Kes 


eS 


the 


are 


Four similar 


4 


modules are required for each other language interface of 


tae MLDS. — For example, there are four. sets of these 
modules "hele eee set is for the relational/SQL language 
interface, one for the hierarchical /DL/I language 
interface, one 1 the network/CODASYL language 
interface, and the last one tor the entity- 
relationship/Daplex language interface. However, if the 


user writes the transaction in the native model e-—sim Die 
there is no need of any interface. 

In our implementation of the relational /S@QL 
language interface, we develop the code for the tour 
modules. However , we do not integrate these modules with the 
BUS as shown in Figure 1. The Laboratory of Database 
Systems Research at the Naval Fostgraduate School is in the 
process of procuring new computer equipment for oe EDS. 
When the equipment 15 installed, the KDS will be perted over 
to the new equipment. The MLDS software will then be 
Integrated with the EDS. Although not a very ditficulit 


undertaking, 1t may be time consuming. 


C. THE KERNEL DATA MODEL AND LANGUAGE 

The choice of a kernel data model and a kernel data 
language is the key decision in the development of a 
multi-lingual database system. The overriding questicn, 
when making such a choice, 18 whether the kernel data 


model and kernel data | language 1s capable Ds 


ev 


supporting the required data-model transformations and 
data-language translations for the language ver pee 

The attribute-based data model proposed by Hsiao 
CRef. 4], extended by Wong CRef. 5], and studied by Rothnhnie 
CRef. 6], aliong with the attribute-based data language 
(ABDL), defined by Banerjee (Ref. 71], have been shown to be 


acceptabie Candidates for the kernel data model and kernel 


| 


data language, respectively. : 


*. Why is the determination of a kernel data model and 
kernel data language so important for a MLDS? No matter how 
multi-lingual the MLDS may be, if the underlying database 
system (a “KDS) is slow and inefficient, then the 
interfaces may be rendered useless and untimely. Hence, 
1t 1S important that the kernel data model and kernel 
language be supported by a high-performance - and great-— 
Capacity database system. Currently, oniy the 
attribute-based data model and the attribute-based data 


language are supported by such a system. This system is 


the multi-backend database system (MEDS) CrKef. 14]. 


D. THE MULTI-BACKEND DATABASE SYSTEM 

The muliti-backend database system (MEDS) has been 
designed to overcome the performance problems and upgrade 
issues related to the traditional approach of database 
system design. This goal is realized through the 


utilization of multiple backends connected in a parallel 
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fashion. These backends have identical hardware and 
replicated software and their own disk systems. . In a 
multiple backend configuration, there is a backend 
controller, which is responsible for 8 per nen nG the 
execution of database transactions) and for interfacing 
with the hosts and users. The backends perform the 


database operations with the database stored on the disk 


system of the backends. The controller and backends are 
cofmmected by a communication bus. Users access the system 
through either the hosts or the controller directly (See 


PAgure <=) . 
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Figure 2. The Multi-Backend Database System. 
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Performance gains are realized by increasing the number 
of backends. If the size of the database and the eee 
of the responses to the transactions remain constant, then 
MBDS produces a reciprocal decrease in the response 
times for the user transactions when the number of 
backends 1S increased. On the other hand, if the number of 
backends 1s increased proportionally with the increase in 
databases and responses, then MEDS Produces invariant 
response times for the same transactions. A more 


detailed discussion of MBDS can be found in CRef. 8]. 


E. THESIS OVERVIEW 

The organization of our thesis is as’ follows: In 
Chapter 2, we discuss the software engineering aspects of 
cur implementation. This includes a discussion of our 
design approach as well as areview of the global data 
structures used for the implementation. In Chapter 3, we 
Cutline the functionality of the | language interface 
layer. In Chapter 4, we articulate the. processes 
constituting the kernel mapping system. In Chapter 3, we 
provide an overview of the kernel controller. In Chapter 
6, we describe the kernel formatting system. In Chapter 
7, We conclude the thesis. | 

Appendix A covers the data structures diagrams for the 
shared and local data. The detailed specifications of the 


interface modules, i.e., LIL, KMS, KC, and KFS, are given in 


Appendices B, C, OD, and —E, respectively. Appendix F is a 
users’ manual for the system. The specifications of the 
source data language, SQL, and of the target data 


language, ABDL , can be found in either CRef. 9] Or 


CRef. 31. 
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Il. SOFTWARE ENGINEERING OF A LANGUAGE INTERFACE 


a eS ee a a ee a ee —_ mt ee ee ee = SS ce ee se 


In this chapter, we discuss the various software 
engineering aspects of developing a language interface. 
First, we describe our design goals. Second, we outline 
the design approach that we took to implement the interface. 
Included in- this section are <~ discussions of our 


implementation strategy, our “software development 


techniques, and salient characteristics of the language 


interface software. Then, we provide a crifique of our 
implementation. Fourth, we describe the data Structures 
used in the interface. And finally, we provide = an 


organizational description of the next four chapters. 


A. DESIGN GOALS 

We are motivated to implement an S@L interface for a 
MLDS using MBDS as the kernel database system, the 
attribute-based data model as the kernel data model, and 
ABDL as the kernel data language. It 1S important to note 
that we do not propose changes to the kernel database system 
Or language. Instead, our implementation resides entirely 
an the host Sanereae. All user transactions in S@L are 
processed in the SQL interface. MBDS continues to 
receive and Process requests in the syntax and semantics of 


ABDL. 


In addition, we intend to make our interface 
transparent to the user. For example, an employee in a 


corporate environment with previous experience with SQL 


could log into our system, issue an SQ@L request and 
receive result data in a relational format, Pre. , a 
table. The employee requires no training in ABDL or MBDS 


procedures prior to utilizing the system. 


; 9% 
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B. AN APPROACH TO THE DESIGN 
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i. The Implementation Strategy 
There 1S a number of different strategies we couid 
have employed -.in ‘the implementation of the SQL lanquage 


interface. for example, there are the build-it-twice 


full-prototype approach, the level-by—-level top-down 


approach, the incremental development approach, and the 
advancemanship approach (CRef. 10: pp. 41-461. We have 
predicated our choice on minimizing the "software-crisis" 


as explained by Boehm CFRef. 1@: pp. 14-211. 

The strategy we have decided upon is the level-by- 
level top-down approach. Our choice 1s based on, first, 
a time constraint. The interface has EG be developed 
within 4&4 specified time, specifically, by the time we 
graduate. And second, this approach lends itselt to the 
natural evolution of the interface. The system 15S 
initially thought of as:'a “black box" (see Figure 1) that 


accepts SOL transactions and then returns the appropriate 


results. The "black box" ius then decomposed into its 
four modules (i.e., ee3 Ce KMS, KC, and KFS). These 
modules, in turn, are further decomposed into the 
necessary -functions and procedures to accomplish the 
appropriate tasks. 

2. Jechnigues for Software Development 


In order to achieve our design goals, it 1s 


a 


important ‘to employ effective ~ 


software engineering 
techniques during all phases of the- software development 
life-cycle. These phases, as defined by Ledthrum CFef. 11: 


p. 2/7], are as follows: 


A) - +s 


(1) Requirements Specification - This phase involves 
stating the purpose of the software: what is to be 
done, not how it is to be done. 

(2) Design —- During this phase an algorithm is devised 
to carry out the specification produced in the 
previous phase. That 1s, how to implement the sys- 
tem which is specified during this phase. 


(3) Coding —- During this phase the design is translated 
into a programming language. 


(4) Validation —- During this) phase it is ensured 
that the developed system functions as originally 
intended. That is, it is validated that the system 
actually performs what it 1s supposed to do. 

The first phase of the life-cycle has already 
been performed. The research done by Demurjian and Hsiao 
CRef. 1] has described the motivation, goals, and 
structure of the MLDS. The research conducted by Macy 


(Ref. 2] and Rollins CRef. 3] has extended this work to 


describe in detail the purpose of the S@L interface. 
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Hence, the requirements specification is derived from the 


above research. 


We have developed the design of the system using 
the above specification. A Systems Specification Language 
(SSL) CRef. 12] is used extensively during this phase. The 
SSL has permitted us to approach the design from a very 
high-level, abstract perspective by : 


Ci enhancing communications among program team 
members, 


(2) reducing dependence on any one individual, and 


CS) Producing complete and accurate documentation 
of the design. : 


Furthermore, the SSL has allowed us to make an easy 
transition from the design phase to the coding phase. 

We have used the C programming language [CRef. 13] to 
translate the design into executable code. Initially, we 
were not conversant in the language. . However, Our 
background in Pascal and the simple syntax of C have made it 
easy for us to learn. The biggest advantage of using C 15 


the programming environment that it resides (1.e., the UNIX 


Cperating system). This environment has permitted us to 
partition the S@L aiunterface and then manage these parts 
in an effective and efficient manner. Perhaps. the only 


disadvantage with using C 1s the poor error diagnostics, 
having made debugging difficult. There 1s an on-line 
debugger available for use with C in UNIX for debugging. 


We have avoided. this option and instead used 


) 


eaten compilation and diagnostic print statements 
to aid in the debugging process. ae callPiaes See 
system we have used a traditional testing technique, 
1.@., path testing CRef. 14]. We have checked boundary 
cases such as the nested select and the single select. 
And we have tested those cases considered "normal". ee 
is noteworthy to mention that testing, as we have done it, 
does not prove the system correct, ut can only ~ indicate 
the absence of problems with the- cases that have been 
tested. 


—— 


=. Characteristics of the Interface Software 
In order for the S@L interface to be successful, we 
have realized that it must be well designed and well 
structured. Hence, we are cognizant ot certain 
characteristics that the interface must nossess. 
Specifically, it must be simple. In other words, it must be 
easy to read and comprehend. The C code we Rave written 
has this characteristic. For instance, we often write the 
code with extra lines to avoid shorthand notations 
available in C. These extra lines have made the 
difference between comprehensible code and cryptic 
notations. 
The interface software also must be understandable. 
This must be true to the extent that a maintenance 
programmer, Or example, can easily grasp the 


functionality of the interface and the relation between it 
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and the other pieces of the system. Our software 
possesses this characteristic. and does not have any hdden 
side-effects that could Eee ay ee months or years from 
now. AS a matter of fact, we. have intentionally 
minimized the interaction between procedures to alleviate 
this problem. 


The interface must also be maintainable. This 1s 


important in light of the fact that almost 78% of all of 


the. software life-cycle costsS are incurred after the 
software becomes operational, 1.€., in the maintenance 
shase. Theme are™ software engineering techniques we 


employed that have given Cie SOL interface this 


characteristic. For example, we require programmers ES 
document changes to the interface code when the change is 
made. Hence, maintenance programmers have current 


documentation at ail times. The problem of trying to 
figure out the functionality see a program with dated 
decumentation 1s alleviated. We also required the 
programmers to update their SSL Specification as the code is 
being chanced. Truss, the SSL specification consistently 
corresponds to the actual code. Im addition, the data 
Structures are designed to be general. Thus, 1t 15 an easy 
eae to MOGClty or rectify these structures to seer the 
demands of an evolving system. 

The research conducted by Seqwiees en and Hs1ao 


fRef. 13 orevides a high-level specification of the MLDS. 
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The peiee written by Macy CRef. 2] and Rollins (CRef. 3] 
extend the above work and provide a more ae: 
specification of an SQL language interface. This 
thesis outlines the actual implementation of an SQL 
interface. The appendices provide the specification SSL 
for this implementation. 

A final characteristic that an S@L interface should 
have is extensibility. A software Product must be designed 
in‘a manner that permits the easy modification and addition 
of code. . In this light, we have placed "stubs" in the 
correct locations of thes KFS sete permit the easy 
insertion of the | code needed to handle multiple 
horizontal screens of output. In addition, we have 
designed our data structures in a manner that will 
permit subsequent programmers to easily extend them to 


handle not only multiple users, but also other language 


interfaces. 


C. A CRITIQUE GF THE DESTGR 

Our implementation of the SG@L interface possesses all of 
the elements of a successful software product. As noted 
previously, it is simple, understandable, maintainable, and 
extensible. Our constant employment of modern software 
techniques have ensured ine success. 

However, there are two techniques that are especially 


worthy of critiques. The first of these is the use 


of the SSL. Initially, we have Pelt that the 


implementation language may also serve as the language to 


specify program algorithms. However, in doing sa, we have 
stifled our creativity. This is because we are 
concentrating not only on what the algorithm does, but 


also on what the constructs (data structures) of the 
algorithm are. The use of the SSL has permitted us to 
concentrate ‘on the functionality of ithe algorithm without a 
heavy concentration on its particular -constructs. This has 
allowed us to view the algorithm in a detached manner so 
that the most feo eS ie implementation for the 
constructs can be used. Although we have initially felt 
tRat the development of the program with the SSL may be too 
time-consuming, our opinions are changed when we have 
realized the advantages of the SSL and the overall 


complexity of the S@QL language interface. 


The way in which the data structures are designed is 


the other noteworthy software engineering technique. 
Reing relatively inexperienced programmers, we are 
inclined to use static structures. Hence, we have made 


extensive use of structures which are bound at compile time. 
We soon realize that in doing so, the computing resources 
(®.Qg., data space) of the system are being depleted guite 
mapidly. Therefore, it is necessary for us to design the 
data structures in away that they can Be managed in a 


dynamic fashion. Most of the data structures of the 
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SQL interface are linked lists. This design affords us 


the most convenient way to efficiently utilize the 
resources of the system. It is an easy task to use the C 
language’s malloc (memory allocate) function to 


dynamically create the elements of a list as we have needed 
them. In addition, the free command is useful in 
releasing these same elements to be used again. 

bY 

8 
D. _ THE DATA STRUCTURE 

The S@L language interface has ‘been developed as a 

Single user system that at some point will be updated to a 
multi-user system. ‘Two different concepts of the data are 
used in the language interface 


1. Data shared by all users. 


ia Data specific to each user. 


The reader must realize that the data structures used 
in our interface and described below have been 
deliberately made generic. Hence, these same structures 


support mot only our S@L interface, but the other language 
interfaces as well, 1.e., DL/I, CODASYL-DML, and Daplex. 
is ata Shared by All Users 


The data structures that are shared by all users 


are the database schemas defined by the users thus far. 
In our case, these are relational schemas, consisting 
of relations and attributes. These are not only shared 


by all users, but also shared by the four modules of the 


MLDS, 1.2@e, LIL, KMS, KC, and KFS. Figure 3 depicts the 
first data structure used to maintain data. se a | is 
important to note that this structure is represented as 
union. Hence, it is generic in the sense that a user can 


utilize this structure to support SQL, DL/I, CODASYL-DML, 


or Daplex needs. However, we will concentrate only on 
the relational model. In this regard, the first field of 
this structure points to a retord that  * contains 
information about a relational. database. Figure 4 
illustrates this record. The first field 1s just a 


character array containing the name of the. relational 


> mm ¢ 


database. The next field contains an integer value 


union dbid_node 


{ 
struct rel _dbid_node *rel; 
Se icic c hie_dbid_node *#hie; 
Sceruee net _dbid_node net; 
struct  ent_dbid_node *#ent; 
+ 


Figure 3. The dbid_node Data Structure. 


struct rel_dbid_node 


. 


char nameCDBNLength + 14]; 
int num_rel;: 

struct rel node *#first_ rel; 

struct rel node *curr_rel; 

Scruce rel dbid node *next_db; 


a 
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Figure 4. The rel_dbid_node Data Structure. 


representing the number of relations in the database. The 
third and fourth fields are pointers to other ea 
Sen eeaionine information about each relation in the database. 
Specifically, the third field points to the first relation 
in the database while the fourth field points to the 
current relation being accessed. The final field is just a 
pointer to the next relational database. 

The record rel_node containstinformation about = each 
relation in the database. (See Figure S.) This structure 
1s Organized in much the same fashion that the rel_dbid_node 
is organized. The first field of the record holds the name 


a 


of the relation. The next field contains the number of 


attributes in this relation. The third and fourth fields 
point to other records which contain data on the first 


and current attribute of this relation. And finally, 
the last field is a pointer to the next relation in this 


database. 


struct rel_node 


char nameCRNLength + id; 
int num attr; 

struct rattr_node +$h rie ater 5 

struct rattr_node ee Utero ore 

struct rel node #next_rel; 


oY: 
J 


Figure 3S. The rel_node Data Structure. 
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Figure 6 shows the structure of the final record 
type used to support the definition of the Me cs ial 
database schema. The first field is also an array, 
holding, in this case, the name of the attribute. The 


second field serves as a flag to indicate the attribute 


F 


type. For instance, an attribute can either be an integer, 
a floating point number, or ae string. The characters 
See "Sand = los" are used, reSpectively. The third 


field indicates the maximum length that a value of this 
attribute type may possibly have. For example, if this 


field is set to ten and the type of this at crt OU ee Ss a 


string, then the maximum number of characters that a 
Yalue of this) attribute type may have is ten. The fourth 
field is also a flag used to indicate whether or not 


this particular attribute isa key. The last attribute 
just points to the next attribute in this relation. The 
reader may refer to Appendices B through EF to examine how 


these data structures are used in the SSL. 


Struct rattr_node 


- 


char nameCANLength + id; 
char type; 

int length: 

int key_flag; 

struct rattr_node *¥next: 


xX 
~] 


Figure 6. The rattr_node Data Structure. 
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This category Of data represents information 


needed to support each user's Particular interface 
needs. The data structures used to accomplish this’ can 


be thought of as forming a hierarchy. At the root of this 
hierarchy is the record type user_info that maintains 
information on all of the current users of a particular 
language interface. (See Figure 7.)* The user_info record 
holds the ID of the user, a unzon that describes a 
particular interface, and a pointer to the next user. The 


union field is of particular interest to us. . AS noted 


= = 


earlier, a union ae as a generic data structure. In 
this case, the union can hold the data for a user accessing 
either an S@L language interface, a DL/I LIL, a CODASYL- 
DML LIL, or a Daplex LIL. The 1li_info union is shown in 
Figure 8. 

We are only interested in the data structures 
containing information for each user that pertains to the 


SQL language interface. This structure is referred to as 


struct user_infto 


fr 
% 


char uidCUIDLength + 14; 
union li_info li_types 
struct user_into *#next_user; 


7%, 
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Figure 7. The user_info Data Structure. 
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{ 
struct sql_info sql: 
Struct eile ht © Gael 
struct dmi_info elimi 
struct dap_info dap; 
+ 


Figure 8. The li_info Data Structure. 


sql_info and is depicted in Figure 9. The first field of 
Epes “Steueture, “eurr db_info, ist itself a record and 
contains Currency information on the Gatabase being accessed 
by a user. The second field, file, is also a record. The 
file record contains the file descriptor and f11e@ identifier 
of a file of SQL transactions, 1.@., either queries or 
Creates. The next field, sgqi_tran, 1S also a record, and 
holds information that describes the S@L transactions 
to be processed. This inciudes the number of requests to 


be precessed, the first request to be processed, and the 


struct sqli_info 


fr 
. 


Seruce eure Ub intro Gurr_db; 
struct file_info file; 
struct tran_intfo sqi_tran; 
int operation; 
struct ddr inte #ddi_ files; 
struct tran_info *#abdl_ tran; 
union kms_info kms_data; 
union et Sor ite kf=s data; 
union Me Line ke data; 
ee error: 


. 
a 


Srctmenv- tme Sal into bata Sceucrcure. 


Current request being processed. The fourth field of the 
sgl_info record, operation, is a flag that yee the 
Operation to be per fonmedi. This can be either the loading 
of a new database oor the execution of a request 
against an existing database. When this field represents 
the execution of a request, it is encoded with the ABDL 
request type to be executed. The next field, ddli_files, 
is a pointer to a structure descriBSing the descriptor file 
and- template file. These files contain information about 
the ABDL schema corresponding to the current relational 
database being _ processed, 1.e. the ABDL. schema 
information ee a arenes? defined relational database. The 
Sixth field, abdl_tran, 1S a pointer to ae record that 
describes the ABDL equivalents to the transactions written 
in SQL 1.e@., the translated SOL requests. 
Specifically, this is the first ABDL request, the current 
ABDL request, and the number of ABDL requests to be 
processed. This data 1s provided by the KMS and used By 
the EC. The mext three fields, kms_data, kc_data, and 
kfs data, are unions that contain information that is 
reguired by the KMS, KC, and KFS. These will be described 
in more detail in the next four chapters. The last 
field, error, is an integer value representing a specific 


error type. 
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E. THE ORGANIZATION OF THE NEXT FOUR CHAPTERS 

The following four chapters are meant to provide the 
user with a more detailed analysis) of ‘the modules 
constituting the MLDS. Each chapter will begin with = an 
overview of what each particular module does and how it 
relates to the other modules. The actual processes 
performed By each module are then discussed. This includes a 
description of the actual data structures used by the 
modules. Each chapter concludes ‘with a discussion of 


module shortcomings. 


III. THE LANGUAGE INTERFACE LAYER (LIL) 


The LIL is the first module in the S@L mapping process, 


and 1s used to control the order in which the other 
modules are called. The LIL allows the user to input 


transactions from either a file or the terminal. G 
peaneactten can take the form of either creates for a new 
database Or queries against an exfsting database. The 
mapping process takes place when the LIL sends a single 
transaction to. the. KMS. After the transaction has been 
received by the KMS, the KC 1S called to process the 
transaction. Control always returns to the LIL, where the 
user can close the session by exiting to the operating 
system. 

The LIL 1s menu-driven. When the transactions are read 
from either a file or the terminal they are stored in a data 
structure called rel req info. If the transactions are 
creates they are sent to the KMS in sequential order. ie 
the transactions are queries the user will be prompted by 
another menu to selectively pick an individual query to be 
processed. The menus provide an easy and efficient way to 
allow the user to see and select the methods in which to 
perform the mapping functions. Fach menu 1s tied ta its 


predecessor so that Dy exiting each menu the user is being 


moved up the menu "tree". This allows the user to perform 


multiple tasks in one session. 


peomeeetl PROCESS 


In this section we discuss the processes and actions 


performed by the LIL. These processes are presented in 
the order in which they are encountered during a 
typical session. The data structures used heavily by 


a 
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the Lil are discussed first. 
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1. Important Data Structures 
The LIL uses two data structures to store the 
-user’s transactions and to control which transaction is to 
be sent ta the KMS. It is important to note here that 
these data structures are shared by both the LIL and the 
KMS. 
The first structure is named tran_info and is’ shown 
in Figure 19. The first field of this’ record, first _req, 
contains the address of the first transaction of the 


transaction list that was read from a file or the 


terminal. The second field, curr_req, contains the 


struct tran_info — 


I 
1S 


struct rel_req_info *first_req: 
struct rel_req_info *curr_req; 
ae no req: 

> 


Figure 1@. The tran_info Data Structure. 


address of the transaction currently being processed. 
The Lit sets this pointer to the transaction that Spe KMS 
will next process, and then calls KMS. The third field, 
nmo_req, contains the number of transactions currently in 
the transaction list. This number is used for loop 
control when printing the tramsaction 1iscteto the .secreeneas 
when searching the list for a transaction to be executed. 
The second data structure ased by LIL is named 
rel_req_info. Each copy of this .structure represents a 
user transaction and thus , is an element ear the 
transaction list. The rel _req_info is given in Figure ii 


The first field of this record, req, 1s a character string 


that contains the actual SQL transaction. The second 
field, in_req, 1s a pointer to a list of character arrays 
that each contain a single line of one transaction. 
After all lines of a transaction have been read, the 
' line list is concatenated to form the actual 
transaction, req. The third field of this Structure, 


req_len, contains the number of characters the transaction 


Struct rel_req_info 


{ 
char *req: 
Struct temp_str_info *1in_redq; 
int req len: 
Struct rel_req_info *#next req; 


%. 
4 


Figure ii. The rel_req_info Data Structure. 
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occupies. It is used to allocate the correct and 
minimal amount of memory space for the transaction. The. 
last field, next_req, 1S a pointer to the next Cranes on 
Structure rel _req_info, in the transaction list. 
=. Procedures and Functions 

The LIL makes use of a number of procedures and 
functions in order to create the transaction list, pass 
elements of the list to the KMS, a@d maintain the: database 
schemas. Fach of these procedures -and functions will not 
be described in detail, but a general description of the 
LIL process will be discussed. 

Be iad ta oles) on 

The MLDS is designed to be able to accommodate 

multiple users, but 1s implemented to support only a single 
user. To facilitate the transition from a single-user 
system to a multiple user system, each user possesses his 
Own copy of a user data structure when entering the 
system. This user data Structure stores all of the 


relevant data that the user may need during their session. 


All four modules of the mapping process make use of this 


structure. The modules use many temporary storaqce 
Variables in performing their tasks or for passing data 
between modules. The transactions, in user data 


language and mapped kernel data language form, are also 
stored in each user data structure. It 185 easy to see 


that the user structure provides consolidated, centralized 
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control for each user of the system. When aiuser logs onto 
the system, a user data structure is allocated and 
initialized. The user ID becomes the Gis Bingueneiee 
feature to locate and identify different users. The 
user data structures for all users are stored on a linked 
list so that when a new user enters the system, their 
initialized user data structure is appended to the end of 
the list. In our current environment there is onlyon single 
elément on the user list. In a future environment, when 
there are multiple users, we simply adopt the append 
Operation mentioned above. 
b. Creating the Transaction List 

There are two operations the user can 
perform on the database schemas. A user can create a 
new database or process queries against an existing 
database. The first menu that is displayed prompts the 
user for which function to perform. Each function 
reoresents a separate procedure to handle the specific 


Circumstances. This menu looks like the following: 


Enter type of operation desired 


(1) - load a new database 
(p) - process old database 
(x) - return to the operating system 


AG LON, —- => 


For either choice (1.e., 1 or p), another = menu 


is displayed to the user asking for the mode of input. 


This input may come from a data file or interactively from 


the terminal. The generic menu looks like the following: 


Enter mode of input desired 


(f) - read in a group of transactions from a file 

(tC) - read in transactions from the terminal 

(x) —- return to the previous menu 

AcTION -——==> _ 
Again, each mode Of input picked corresponds ee a 
: 2 4 

different Jase ee be performed. The transaction list 
fetereated by reading from the file or terminal 
looking Gen an end-of—-transaction marker or an end-of- 
file marker. . These flags tell the system — — one 
transaction has ended and when the next transaction 
begins. When the list is being created, the pointers to 
access the list must be initialized. These pointers, 


first req and curr_req, have been described earlier in the 
data structure SScleine 7 vsishels pointers are set to the 
first transaction read, i1n other words, the head of the 
transaction list. 
es Accessing the Transaction List 

Since the transaction 11st stores both creates 
and queries, two different access methods must be 
employed to send the two types of transactions tO sae 
Rida. We discuss the two methods separately. In bath 
cases the KMS accesses a single transaction from the 


transaction list. It does this by reading the transaction 


pointed to by the request pointer, curr_req, of the data 
structure, tran_info. ee, Suaeee 1Q@ again.) Shenedetaer 1t 
is the job of the LIL to set this pointer toa the 
correct transaction before calling the KMS. 

(1) Sending Creates to the KMS. When the user 
has specified the filename of creates (if the input is from 
a file) or typed ina set of creates (if the input 1s from 
the terminal), any further use® intervention is not 
required. To produce a new database, ¥t does not make sense 


to process only a single create out of a set of creates, 


since they all must be processed in a specific order. 


Therefore, the teacnaeeien list of creates is sent to the 
EMS In its Mentigety. A program loop traverses the 
transaction list, calling the KMS for each create in the 
bi Sse. 

(=) Sending Queries to the EMS. In this 
case, after the user has specified his mode of input, 
he conducts an interactive session with the system. First, 
ali queries are listed on the screen. As the queries are 
listed from the transaction list, a number is assigned to 
each query in ascending order, starting with the number one. 
The number is printed on the screen to the left of the 
first line at each query. Next, an access menu is 


displayed which looks like the following: 
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Pick the number or letter of the action desired 
(num) - execute one of the preceding queries 


(d) - redisplay the list of queries 
cee) —- return to the previous menu 
ae LOM ————> _ 
Since queries are independent items, the order in which 
they are processed does not matter. The user has the 
choice of executing any number of queries. A loop causes 
the query listing and menu to be redisplayed after any 


query has been executed so that further choices may made. 


d. Calling the KC 


As mentioned before, the LIL acts as the 
control module for the entire system. When the KMS has 
completed its mapping process, the transformed 


transactions must be sent to the KC to interface to the 
kernel database system. For creates the KC 1s called 
after all creates on the transaction list have been sent 
ad the KMS. The mapped creates reside in another list 
that the KC is going to actess. Since queries are 
independent items, the user should wait for the results from 
one query before issuing another query. Therefore, after 
each query has been sent to the EMS, the KC is immediately 
Called. The single mapped query resides on the same second 
Lyset for the creates which the FEC can access easily. 
e. Wrapping—-up 
Before exiting the system, the user data 


Structure described in Chapter II must be deallocated. The 


memory occupied by the user data structure 1s freed up and 
returned to the operating system. Since all of the user 
structures reside inalist, the exiting user’s node must 


be removed from the list. 


Be SHORTCOMINGS 

As used in this chapter, a transaction consists of a 
Single), eQueseecnaa database. A eight i would normally 
be _ allowed ne contain SWiles ele requests, such as an 
inser a query, and then a ite on some portion of a 
database. This feature is not incorporated into the 


present system,.. but. it could be easily integrated at some 


later date. 
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IV. THE KERNEL MAPPING SYSTEM (KMS) 


The KMS is the second module in the S@L mapping 
interface and is called from the language interface layer 
(LIL) when the LIL has received S@L input en re from the 
user. The function of the KMS is to: (1) parse the request 
to validate the user's SQL ‘syntax, and (2))  tranctates = ce 
map , the request to an equivalent-ABDL request. Once an 
appropriate ABDL request, or set of requests, has been 
rormeaq, it as made available to the.kernel controller (KC) 


which then processes the request for execution by MEDS. The 


EC is to be discussed in Chapter V. 


Seem OVERVIEW OF THE MAPPING PROCESS 

From the description of the KMS functions above we 
immediately see the requirement for a parser as a part of 
the KMS. This parser validates the SOL syntax of the input 
request. It is the driving force behind the entire mapping 
system. 

1. The EMS Farser / Iranslator 

The EMS parser has been constructed By utilizing 

Pe ote Consider Compiler (YACC) (Ref. 153. YACC is a 
Program generator designed for syntactic processing of token 


input streams. Given a specification of the input language 


structure (a set of grammar rules), the user’s code to be 
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invoked when such structures are recognized, and a low-level 
input routine, YACC generates a program that Vivato 
recognizes the input language and allows invocation of the 
user ’s code throughout this recognition process. The class 
of specifications accepted is avery general one: LALK(1) 
grammars. It 1S important to note eee the user’s code We 
speak of . here 1s our mapping code that 1s going to perform 
the SQ@L-to-ABDL translation. As {the low-level input 
routine, we have utilized a Lexical Analyzer Generator (LEX) 
CRef. i6]. LEX is a program generator designed for lexical 
processing of input character streams. Given a regular- 
expression een sei of the input strings, LEX generates a 
Program that partitions the input stream into tokens and 
communicates these tokens to the parser. 

The parser produced by YACC consists of a finite- 
state automaton with a stack and performs a top-down parse, 
with left-to-right scan and one coven look-ahead. Coeneror 
of the parser begins initially with the highest—-level 
Grammar rule. Control descends through the grammar 
hierarchy, calling lower and lower-level grammar rules which 
search for appropriate. tokens in the input. As the 
appropriate tokens are recognized, some portions of the 
mapping code may be invoked directly. In other cases, these 
tokens are propagated back up the grammar hierarchy until a 
higher-level rule has been satisfied, at which time further 


transiation is accomplished. When all of the necessary 
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lower-level grammar rules have been satisfied and control 
has ascended to the highest~level rule, the eye and 
translation processes, and, therefore, the mapping process, 
is complete. In Section B, we give an illustrative example 
of these processes. 

2. The KMS Data Structures 

The KMS utilizes, for the most part, just four 
structures ‘defined in ‘the intetface. Lt aneturally, 
requires access to the S@L input request and ABDL output 
request structures discussed in Chapter II, the rel _req_info 
and ab_req_info structures, respectively. However, the four 
data <a e ie discussed here are only those unique 
Eocene KMS. 

The first of these, shown in Figure 12, 18S a record 
that contains information accumulated by the KMS during the 
grammar—-driven parse that 1s not of immediate use. as 
record allows the information to be saved until a point in 
the parsing process where it can be utilized in the 
appropriate portion of the translation process. The first 
field in this record, first_tgt, is a pointer to the head of 
a list of attribute names. These are the attribute names 
specified by the user request to amie 4c information from, 
cr insert Weer dation Tees Ae database. This 1ist &s Gm y 
utilized during SELECT or INSERT operations. The second 
field, templates, is also a record and holds the relation 


name(s) referenced in the user query. DUI Dey jeLn 
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struct rel_kms_info 


{ 

Struct target_list_info *first_tgt; 
Struct templates_info templates; 
Struct insert_list_info *first_val; 
char *temp-str; 
char *join_str; 
Struct rel_kms_info ¥next_nest; 
3 


Figure 12. The rel_kms_info Data Structure. 


5 A @ “ 
operations, two relation names may be kept in this”) record. 


The third field, first_vai, 1S a Senco to the head of a 
Gee of values. These are the values that an INSERT request 
desires inserted into the database. The Poet field, 
temp str, is a pointer to a variable-length character 
string. The character-string length is a function of the 
input request length, and is allocated, when required, to 
accumulate aintermediate translation results while parsing 
the WHERE boolean-clause of a user request. The fifth 
field, join_str, is also a pointer to a variable length 
character string. The character-string lenqth 1S again a 
function of the input request length, and it is allocated to 
accumulate the translation for the second ABDL RETRIEVE 
request that 1S generated in response to a join operation. 
The sixth field, next_nest, 1S a pointer to another record 
of the same type. The next_nest field 15 used only during 


the translation of a nested SELECT statement, in which case 


we require a list Of rel_kms_info structures, one 
corresponding to each level of the nested Sate Query. 
The remaining three data structures, shown in Figure 


1S, gare records that are pointed to by the rel _kms_info 


tA 


record, as just described. Respectively, they represent a 
list of attribute names (the target list), a record of 
relaticn names (the templates), and a list of attribute 
values (the insert list). ANLeggth and RNLength are 
constants defining the maximum lengths of attribute and 
relation names, SSS Le vee. It should be noted that the 


Pouuoeeeneld 1m the insertilist info record is 4 pointer to a 


2 


Variable length character ‘string. Although attribute-names 


have a constant maximum length constraint, the length of 


struct target_list_info 


t 
char namelCANLenath + 1d: 
char tgt_relCRNLength + 14; 
struct target_list_info *next_attr; 


as 
2 


struct templates_info 


S 
X 


cher namelCRNLength + 114; 
char name2CRNLength + 14; 


%, 
J 


Struct insert_list_info 


St 
. 


Ginats *value; 
struct insert_list_info *next_val; 
_ 


ci 


Figure 13. Additional KMS Data Structures. 


4 


attribute values in the database is limited only by the 
constraint placed on them by the user in the original 
database definition, and as such they may be of varying 
lengths. 

At the end of the mapping process, before control is 
Surrendered to the LIL, ei data Structures that are unique 
to KMS which have been allocated during the mapping process 


are returned to the free list. 2 


' 


a FACILITIES PROVIDED BY (RS IMPLEMENTATION 

In this section, we discuss those S@L facilities that 
Nee Provided “by aur implementation of the’ relational 
interface. We somect discuss the SOL to ABRDL translation in 
detail. Rather, we provide an overview of the salient 
features of the KMS, accompanied by one illustrative exampie 
of the mapping process. User-issued sacuieete may take two 
forms, SQL database definitions, or SQL database 
manipulations. Appendix C contains the design of our 
implementation, written in a system specification language. 

1. Database Definitions 

When the user informs the LIL that the user wishes 

to create a new database, the job of the KMS is to build a 
relational database schema that corresponds to the database 
definitions input by the user. The LIL initially allocates 
a new database identification node (rel_dbid node shown 1n 


Figure 4) with the name of the new database, as input by the 


User. The LIL then sends the KMS one database definition at 


a time, which takes the form of an SQL CREATE TABLE request 


as follows: 


CREATE TABLE table name : 


field name_1 ( type(length) £, NONULL] ), 
field name_2 ( type(length) £C, NONULL]J ), 


field name_n ( typ@(length) £, NONULLI ) 


For each CREATE TABLE request, an additional relation node 
(rel node shown in Figure 2) 1S added to the database schema 
under oon It should be apparent from the 
Preceding CREATE TABLE example that for each relation node, 
we must also add a list of attribute nodes (rattr_node shown. 
in Figure 6) to the schema. The database identification 
node holds the number of relations in the schema and the 
database name, each relation node holds the number of 
attributes in that relation and the relation name, and each 
attribute mode holds the attribute name, type, length, and 
primary key information. 

When the LIL has forwarded all database definitions 
entered by the user, the result is a completed database 
schema, -as shown in Figure 14. The Pe Ae database 
schema, when completed, serves two purposes. First, when 
creating a new database, it facilitates the construction of 


the MEDS template and descriptor files. Secondly. when 


: DBID : 
poe ec ee + 
Vv 
+o “+ +———————— + +——-—-—-—-—-— + +————-—-——— + 
| REL_1 t-—> | ATTR_1 !-——> | ARDRE2 ==... ee eee 
+——-—-———— + te + poo eo ee + +——— + 
Vv 
+------ + a * toe eee + +—-——— + 
| REL2 t——> | AUR okt —— > 0 Ae eee 
pore rt ee + pea a ie a+ +—-—-—-—---— + 
Vv 
tee eee + - $o>—--—— + oe + +———---—--— + 
| REL on i-->,2 ATTR_1 '-——) 129A Rie —— 2 eee eo ee 
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Figure 14. The Relational Database Schema. 


processing requests against an existing database, it allows 
a validity check of the relation and attribute names. I[t 
also serves as a source of information for the type 
checking. 


a 


=. Database Manipulations 

When the user wishes the LIL to process requests 
against an existing database, the job of the KMS is to map 
the user’s SQL request to an equivalent ABDL request. 
Throughout this subsection, we only See examples of the 
translated constructs of our implementation where they 


differ in some respect from those given in the work of Macy 


CRef. 2] and Rollins CRef. 2]. 


a. The SQL SELECT to the ABDL hero eve 

A simple SQL SELECT construct is mapped ve a 
single ABRDL RoRtEVESeconstruct= A simple SELECT is 
characterized as a SELECT-FROM-WHERE block, in which access 
is limited to the information contained in a single relation 
of the database. The SELECT-clause may contain attribute 
names alone, or the aggregate functions (COUNT, SUM, AVG, 
MAX, and MIN) may be applied to any Of the attributes where 
Peeweves sense to do so. The Joe Ga se mae Some ioe in 
an asterisk (#), which signifies that all attributes in the 
relation should be retrieved, in lieu of an exhaustive 
ieest ting. As ¥ ee ee the attribute names may be 
prefixed with the relation name (rel_name.attr_name), even 
thouch only a single relation is being accessed. The FROM- 
oe contains this single relation name. The WHERE-clause 
may contain any number of predicates connected together by 
the boolean operators (AND and ORD . Each predicate may 
utilize the six standard relational operators (=, /=, *, =, 
“=, and <=) to separate the attribute mame and value, or the 
set membership operators (IN, NOT IN, /=ANY, <=ANY, <ANY, 
SANY, 2=ANY, <q=ALL, <ALL, <ALL, Z=ALL) may be used to 
separate the attribute name from an enumerated set of 
Yalues. mimad ly the SELEET-FROM-WHERE Dlock may ode 
optionally followed by either a GROUP HY-clause, or an ORDER 
RBY-clause, whereby retrieved attributes may be either 


Grouped or sorted. 


Ch 
Cn 


A name SQL SELECT construct is mapped to a 

series of ABDL RETRIEVE constructs. A nested SELECT fe 
characterized as a SELECT-FROM-WHERE block, in which the 
WHERE-clause utilizes one of the set membership operators. 
In this instance, however, the operator is followed by 
another complete SELECT-FROM-WHERE block instead of an 
enumerated set of values. Such constructs can be nested to 
any depth. - This allows multiple r@lations to be accessed, 
and their attribute-values compared, while the values 
returned to the user are taken from only a single relation. 
This 15 analogous to an implicit join operation. . An example 


of such a query is as follows: Note that the parentheses are 


optional and need not be included. 


SELECT name, age 
FROM student 
WHERE name IN 
( SELECT name 
FROM faculty ) 


This query would find the mame and age of ali students who 
are also a member of the faculty. It’s ABDL counterparts 


would be as follows: 


feRETRIEVE (TEMBLATE = Fabuliy) Seer a: 


C RETRIEVE ((TEMPLATE = STUDENT) and 
(NAME = *#*#*#*%#¥HHHH) ) CNAME, AGE) J 


a 
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Notice that the first ABDL request corresponds to the last 
(or innermost) S@L request. This is because the sapere nest 
SQL request is the only one that represents a comellet cl 
specified simple SELECT. The results of the first RETRIEVE 
are names which are used by the KC to fill in the place 
holders marked with asterisks in the second RETRIEVE (the 
number of asterisks equals the maximum length of the NAME 
attribute-value). From a single $nested SELECT, the KMS 
generates a series of ABDL RETRIEVEs . before relinquishing 


control to the KC, for subsequent execution of the ABDL 


requests. 


bad ee 


A Foun SOL SELECT construct 1s mapped to a 
Single AHBDL RETRIEVE-COMMON' construct. A join SELECT is 
characterized as a SELECT-FROM-WHERE block, in which the 
FROM-clause contains two relation names. We have already 
seen how the nested SELECT query specifies an implicit join. 
Here we are concerned with explicit joins, where multiple 
tables are accessed, and their attribute values compared, 
with the values returned to the user being taken from two 
different relations. In this instance, the SELECT-clause 
normally contains attribute-names that are prefixed with the 
appropriate. relation name (rel _name.attr_name). This 
eliminates any ambiguity that might otherwise exist. The 
prefixed attribute-names are a required convention in the 


WHERE-clause. An example of such a query is as follows: 


SELECT student.name, faculty.name 
FROM student, faculty 
WHERE student.class = faculty.class ~ 


Assuming each class was only taught By one member of the 
faculty, this query would return a class roster for all 
members of the faculty. Tt’s ABDL counterpart would be as 
follows: 


a 
a 


C RETRIEVE (TEMPLATE = STUDENT) (NAME) 
COMMON (CLASS = CLASS) 
RETRIEVE (TEMPLATE = FACULTY) (NAME) J 


a 


Notice the placement of the square brackets around the ABDL 
request. This represents a single ABDL request, and is 
forwarded to MEDS for execution as a single transaction. 
The use of prefixed attribute names in the SELECT-clause is 
not a necessity, providing that the attribute-names used are 
Valid in both relations. Thus, the last S@L example may be 


entered as shown below to obtain the same results. 


SELECT name 
FROM student, faculty 
WHERE student.class = faculty.class 


b. The S@L INSERT to the ABDL INSERT 
The S@L INSERT construct 1S mapped to a single 


ABDL INSERT “comstruce- If values are to be inserted for 
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each attribute in the relation, there is no requirement to 
list the attribute names. Only ee values need be 
listed; however, they must appear in the correct order (as 
listed in the schema which has been determined during the 
Original database definition of the relation). If values 
are not inserted for each attribute in the relation, 
corresponding attribute names of those attribute values to 
be inserted must also be included ingthe request. 
c. The SQL UPDATE to the ABDL UPDATE 


The S@L UPDATE construct is mapped to ae single 


BBDL sUPDATE censtruct. ABDL does not provide a single- 


a 
= 


request ese ruct ees updates more than one attribute ina 
Before. Thus, we only allow one predicate in the SET-clause 
of the S@L UPDATE query. However, the attribute value iin 
this predicate may be a constant, or an arithmetic 
expression based on the Original value of the attribute. 


ade From tRe@s@l DELETE to ‘the “ABDL DELETE: An 
Example 


The S@L DELETE construct 1s mapped to a single 
Afeek DELETE conetruct. The S@L DELETE may have an optional 
WHERE-clause, so that all records for the particular 
relation may be deleted when the WHERE-clause 1s empty, or 
cnly those records Bae a specific condition may  05be 
deleted when the WHERE-clause is) included. In this 
subsection we will present an illustrative example of the 


mapping process for a simple S@L DELETE request. We begin 


a 


Ly 


by showing the grammar for the delete-portion of the KMS. 
We then step through the grammar and show appropriate 
portions of our design in System Specification Language 


(S50. The entire design is shown in Appendix C. The 


relevant grammar is as follows: 


deletion : DELETE table name _ €E; 


table name : IDENTIFIER;? 


WHERE boolean; 


The source SQL request we will utilize for our example will 


be the following: 


DELETE student 


Tt’s ABDL translation will be as follows: 


C'DELETE ( TEMEEATE = Siuvenil = 


To begin our discussion, let us firse 


synchronize the reader: At the beginning of a mapping 


process, the parse descends the grammar hierarchy searching 


for appropriate tokens in the source that may satisfy one of 
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the grammar rules. Thus, the parser descends through the 
Atha for SELECTs, INSERTs, etc. After finding no eee ee 
tokens for those rules, the parser eventually descends) oan 
the DELETE rules. 

First, when the deletion rule is called, the 
DELETE-token will be recognized. In an attempt to satisfy 
the deletion rule, the table_name rule is then called. The 
table name rule recognizes the IDENTIFIER-token, as the 
STUDENT-token (student converted to upper-case upon input). 
At this time, the table_name-rule is completely satisfied, 
and the Following SSL is invoked: 


table name : DPSENT IF ITER 
{ 
act (!' creating) 
if (! valid _table(’table_name’>) ) 


Pramc (Seeror — relumame not valid”) 
perform yyerror () 
return 
end_if 
end_if 
If we are not creating a new database (as in this case), a 


call is made to the valid_table() function, which checks the 
validity of the IDENTIFIER table name in the relational 
database schema. If STUDENT is not a valid relation name, 
then an error message is printed, and an error routine is 
called. Then we simply return from the mapping process. lice 


STUDENT is a valid relation mame, there 1s no code here for 
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translation; however, control returns to the rule that 
called the table_name mule (ime. , thesdebetiensmule). | 
Next, even though the deletion rule is not 
completely satisfied, we need to perform some translation. 
The following SSL is invoked, before the call is made to the 


E-rule: 


deletion’: DELETE table_name ¢ 


~ 
* copy "CC DELETE ( ". to abdl_string 
copy ‘table name’ to templates 


JS 


The abdl_string begins to be built, as we initially copy 


" Coe DERE LE (0 


into the abdl_ string. The value of the table name (STUDENT) 
Iis)6 6h then copied to the templates data structure, because, at 
this point, we are not certain that it 1¢ of immediate use. 
The reader should note the trailing blank that we placed in 
the abdl_ string. Without going into great detail, which 15 
beyond the scope of this example, it suffices to say that 
this Blank 1s for an additional left parenthesis that we may 
later determine to be required at the beginning of the ARDL 
request, 1.e., when OR is used to connect WHERE-clause 


predicates. 


The next step in the parse is for the deletion 


rule to call the E-rule. The E-rule recognizes the empty 


rule, because the source is now void of additional tokens. 


The E-rule is now completely satisfied and the following SSL 


is invoked: 


E: empty 
{ 
delete _ all = JRUE 


be 


(| WHERE boolean; 


This sets the delete_all boolean variable equal to true. 


Control now reverts to the deletion rule, which is of course 


completely satisfied. Thus, the following SSL is invoked: 


deletion : DELETE table _ name 
= 
€ 
if (delete_all) 
concat "TEMPLATE = ‘table _name’" 
to abdil_ string 
end_if 
concat ")" to abdi_ string 


%. « 
18 


Since we know that the delete_all variable has previously 


been set to true, we now concatenate 
“TEMFLATE = STUDENT” 


to the abdl string. Finally, we concatenate the trailing 
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right parenthesis to the abdl_ string. The trailing right 
bracket (3) 1s concatenated to the abdl_string ee 
recognition of a higher-level grammar rule (one that called 
the deletion-rule), and the mapping process 1s now complete. 

Let us continue with an extension of this 
example. Had the original S@L Source request included a 
WHERE boolean-clause, such as the following, what would have 


happened? 


a 
a 


» 
a 


= 
@ 


DELETE student 
WHERE name = ‘Jones’ 


Its ABDL equivalent is as follows: 
C DELETE ¢( (TEMPLATE = STUDENT) and ‘(NAME = Jecnes)) Jj 


In this instance, when the E— rule is called, the WHERE-token 
would have been recognized, and thus the boolean rule would 
have been called. The boolean rule would have called other 
rules and continued to read the :remainder of the input 
(source) tokens. Refore the boolean rule was called, the 


abdl_ string contained the following: 
pp ieee) = Sg fe ae 
When control returns to the E-rule, from the boolean rule, 
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the abdl_string will contain the following: 


\ 


"{ DELETE ¢ (TEMPLATE = STUDENT) and (NAME = Jones)" 


Then control would revert from the E-rule to the deletion 
rue But this time, since the delete_all variable is not 
set to true in the E-rule, the deletion rule merely 
completes this portion of the tran$lation by concatenating 
anéther right parenthesis to the abdl_string shown above. 
Again, the trailing right bracket is) added at a higher 


level, and the mapping process is complete. 


dl = 6 


C. FACILITIES NOT PROVIDED BY THE IMPLEMENTATION 

Our original intent has been to demonstrate that the 
relational interface could indeed be developed = and 
implemented. As a demonstration, there are some facilities 
that are not included in our implementation. Some of these 
facilities have more to do with providing a user-friendly 
environment, than with supporting a germane relational 
interface. For others, the programming time and effort 
required to incorporate them would be ts90 costly for the 
benefits derived. However, this is not to imply that such 
facilities would not be useful. This section is devoted to 
describing the most prominent features of SQL that are not 


suoported by the language interface. 


1. Interfacing Users 

In our relational interface, there is no aig wot 
a user view. A view may be thought of as a virtual relation 
that has no existence in its own right, but is derived “from 
one or more existing relations. Under our implementation, 
the logical database and the physical database are one in 
the same. Thus, our interface is limited to data .definition 
language (DDL) and data manipulation language (DML) 
statements, and provides no data-control facilities such as 
the GRANT and REVOKE options. Also, all CREATE TABLE 
requests are considered PERMANENT and SHARED. As mentioned 
in Chapter Rite our ARCS Gr YEE data structures are constructed 
to facilitate future use by multiple users. This would 
allow the view concept to be supported by incorporating the 
relational database schemas into the user_information 
structure (user_info shown in Figure 7). These schemas 
would be virtual and user-specific with respect to the 
entire list of database schemas that are still global. 

=. Updating Multiple Attributes 

ABDL does not provide a single-request construct 
which updates more than one attribute in a record. The work 
Of Rollins (Ref. 3: pp. 25-27] has showed that the S@L 
UPDATE ee translated into multiple ABDL requests. AS a 
result, it may be necessary to generate either several 


independent ABDL UFDATEs, a transaction of ABDL UPDATEs 


(specifying the order in which a series of requests must be 
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processed), or an ABDL RETRIEVE, DELETE, and INSERT 
sequence, to accomplish the requested update of multiple 
attributes. We have felt the programming effort involved to 
provide such a facility, although mot complex, is time- 
consuming. 


=e 


S. Retrieving Qualified Groups 

ABDL provides an option whereby retrieved attributes 
may be sorted (the by-~attribute_nam@ option). SQ@L: provides 
a further option whereby those records not satisfying a 
specified condition can then be eliminated (the HAVING— 
condition option). ABDL does not provide a facility for 
checking this ae condition. It could have been 
implemented in the KC; however, we have felt the programming 
effort is too great for the benefits derived. 

4. Retrieving Computed Values 
fini Sse ope1 on sueeeets the inclusion of arithmetic 


expressions involving attribute names in the SELECT-clause 


of S@L requests. An example of this option is as follows: 


SELECT name, weight * 454 
FROM student 


This query would retrieve the name and weight of all 
students. However, the value of the attribute weight would 
be returned to the user in grams (found in the student 


relation in pounds). ABDL does not support the retrieval of 
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computed values; however, this could easily have been 


implemented in the KFS module. We have chosen not to) 


implement, since it does not represent a feature of S@L that 
1s inherently relational. 
3. Eliminating Duplicates 


ae aes ED ees ees ees > ees ees oe — <=> oe ee ee ee ee Oe ee 


The results of a SEEBEET query may contain 


duplicates. The elimination of duplicates 1s normally a 
high-cost operation and often unwarranted. We ,do “ner 
pravide such an option. SOL supperts the elimination of 


duplicates through the use of the UNIQUE operator in the 
SELECT-cl ause. _ Thus, our implementation does not support 
the S@L UNTQUE spemaneee 
6. Retrieval Using UNION 

The work of Rollins CRef. 3S: pp 82-83] has described 
the use of the SQL UNION operator in a query comprised of 
multiple Sbeset constructs. Each SERERa construct 
translated to an equivalent ABDL RETRIEVE construct, and all 
are then processed By MBDS concurrently. Rollins has 
assumed the capability to eliminate duplicates in the 
interface. In as much as such a facility 15S not provided By 


Our implementation, we are not supporting the SQL UNION 


operator. 
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V. THE KERNEL CONTROLLER 


The kernel controller (KC) is the third module in the 
SQL language interface and is called by the language 
interface layer (LIL) when a new database is being created 
Or when an existing database is being manipulated. In 
Pither situation the Lid nee calis the kernel” mapping 
system (KMS) which performs the necessary SOL to ABDL 
translations. Then the KC is called to perform the task of 
controlling the submission of the ABDL transaction(s) to the 
multi-backend database system (MBDS) for processing. If the 
transaction involves creating a new database or 
inserting, deleting or updating information in an existing 
database, contrel 1s returned to the LIL after MEDS 
processes the transaction. If the transaction involves a 
retrieval request, the KC sends the translated ABDL request 
to MEDS, receives the results back from MHDS, loads the 
results into a buffer and calls the LeP De! formatting system 
(KFS) to format the results a buffer at a time. After the 
last buffer is processed by the EFS the resulting table 1s 


displayed and control then returns to the LIL. 


One situation worth noting is the processing of an S@L 
nested-select request. An n-level SQL nested-select is 
maecped to n corresponding ABDL retrieve requests. 


mes 


Only the first ABDL retrieve (which corresponds to the 
innermost select) is a fully~-formed request. All other 


ABDL retrieves which correspond to the outer-level selects 


are sent to the KC by the KMS as request templates. a 
reguest template is an ABDL retrieve request with one 
unspecified attribute value. The KC must use the results 
obtained from the previous ABDL retrieve request (1.e., 


attribute vale) ane the request template to build the 
nett ABDL request, i.e., the KC substitutes the retrieved 
attribute values for the unspecified attribute value in the 
request template. The processing of nested selects is 
manaced by wee oe. 

The procedures that make up the interface to the EDS 
(i1.e@., MBDS) are contained in the test interface (TI) 
CRef. 81d. To fully integrate the KC with the EDS fe We ee 
MBDS), the KC calls procedures which are defined in the Tlf. 
Due to upcoming hardware changes in the MEDS, we decide 
not ahem: est the EFC on-line with the TI. Our solution 
to this problem is to design ne system exactly as if it 
1S interfacing with the TI. However, for each call toa 
T? procedure we create a procedure stub that performs the 
same function as the actual TI procedure. The reader 
should realize that all interactions with the TI procedures 
described in the KC are actually made with these procedure 
stubs, rather than with the on-line TI procedures. 


In this section we discuss the processes performed .-. by 


7@ 


the De This discussion is in two parts. First we 
examine the data structures relevant to the KC, which is 
followed by an examination of the procedures and functions 
found in the KC. Appendix D BP oink the design of 
our KC aimplementation, written in a system specification 
language. 


A. AN OVERVIEW OF THE KC DATA STRUCTURES 


NY 


In this section we will review the data structures 


~ 


a 


mentioned i1n chapter 2, focusing an See structures that 
are accessed and used by the FEC. The first data structure 
that is important ‘to the KC is the record Ra sql_info 
shown in Figure 15. The fields of sql_info contain all 
of the data structures relevant to the KC, but the KC 
only uses several of the fields. The first field of this 


‘record, curr_db, is a record which is used by the FC when 


struct sql info 


S 
i 


struct curr dbermatroe Eur igee > 5 
struct file info file; 
Struct tranwunto sqil_tran; 
igs operation; 
struct tran_info *#abdl tran: 
sigs answer ; 
union kms_info kms_data; 
union kKfs_ info k#s_ data; 
union ke _info ke data; 
“int error; 

vane subreq stat: 


uJ 


Figure 15. The sql_info Data Structure. 
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interacting with MBDS. When the KC sends an ABDL 
transaction to MBDS for execution, the current database 
name must be sent with the request. The current database 
name 1s stored in the curr_db record. 

The next field of the sql_info record type which the EC 
uses 1S operation. This fourth field of sql_info contains 
an integer that tells the KC what type of operation is to be 
performed. ‘There are six possible types of operations 
which correspond to the six operations supported by the KC. 
These operations are a database creation request, a retrieve 


request, a retrieve-common request, a delete request, an 


= 


insert request and aA update request. 

The next field used by the KC is abdi_tran, which is a 
record of type tran_info, and is shown in Figure 16. The 
first two fields of tran_info are variant records which 
store information on ABDL requests. The ABDL requests are 
stored in arecord of type ab_req_intfo, shown in Figure 17. 
Both first _req and curr_lreg initially contain the first ABDL 


request which 1s loaded into the data structure by the EMS. 


Struct tran_info 


< 


union req_info first req; 
un1lon req _infto curr @req; 
ete no_req; 


Tad 


Figure 16. The tran_info Data Structure. 


44 


struct ab_req_infe 


im 
a5 


char . #reqgs 
int rel oo; 
Semuct ab_rel_info enext_ req: 


us 


Fregume 17. The ab reg info Data Structure. 


The no_req tells the KC how many requests are in the linked 
list of the ab_req_info structure. There will normally only 
be one request in this list, udless an SQL nested 
sefect is being processed. In that case, the no_req will 
correspond to the number of levels that there are in the 


neamec select. me first request will always. be a fully- 


bad . 


formed ABDL et while any additional requests will be 
SBDL request templates. The requests or request témpiates 
are stored in the ab_req_ info record. The *req is a 
Pointer to a character string which contains either the 
request cr the request template. The rel_op field 
informs the FC which type of relational operator 15 
contained in the corresponding request or request 
template. The eleven possible operators are IN, NOT IN, 
~“SANY, <=ANY, ==ANY, <ANY, ANY, “<=ALL, j%F=ALL, \<“ALL and 
-ALL. The *next_req 15 a pointer which directs the Ft to 
the next ABDL request. 


The next field of sql_infto that the FC uses is kfs_data, 


which is a variant record into which the respcnses 
received from MBDS' are stored. From this storage bufter 
the KFS extracts the data returned from the KDS to be 


formated. This storage buffer is only used when we are 
processing Sat selects which have been mapped to ABDL 
retrieves. The results of the ABDL retrievals are 
loaded apes! the storage buffer. When the buffer is 
filled the KFS is called. The process of filling the 
buffer and calling KFS is repeated by the KC until all 


results from the 


retrieval have been processed. 


The next field used by the Ke from the sql_info 
record type is kc_data. This field is a variant record 
which contains the record type kc_rel_info. This record 


type holds all of the information that is 
This data structure is shown 1n Figure 
file status 1S a flag used to indicate 


Guar enteand fails result files. Two files 


Steuece Ke Goleta no 


& 
X 


unique to the EC. 


18. The field 


the status of the 


are necessary to 


int file status; 
struct max _info MAX § 

Stmuct min_info mins 

mc num values _ffile; 
int num values_cfile; 
struce nsel_res_info files; 

char *unfin_ret; 

ime beg_con3); 

int end cong); 

int beg_asterisk; 

aaks end_ asterisk; 

int req_lens; 

fate req status; 

int curr_pos; 

ve res _len; 


uw 


Figure i8. 
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The kce_rel_info Data Structure. 


handle SQL nested selects. The future-results file holds 
results from ae Current oe awe being processed by MBDS, 
while ii Current-results file holds the results from the 
previous retrieve request, which are used to build the 
current retrieve request. The records max_intfo and 
min_info are identical data structures. Both structures 
allow for the storage of a character which indicates the 
data type of the attribute-values, 2.e., integers, floating 
point numbers or strings. Both structures also contain a 
variant record which is used for the storage of the 
respective maximum or minimum value encountered in the 
resultant ee ae The num_values _ ffile and num_values_cfile 
indicate the number of values stored in the future or 
Current results file, respectively. The record type of files 
is nsel_res_info. The file field contains two identical 
records of type file info. This record stores a file 
Mame and a file descriptor used for file manipulation in 
the CC programming language. One record is) for the 
current-results file and the other is for the future- 
results file. 

The *unfin_ret is a character array used to store the 
request template sent to the KC by the KMS. The request 
temolate that is stored in the first field of the 
ab _reg_info record type is loaded into unfin_ret. This 
transfer of the request template is necessary so that the 


fully-formed ABDL request that is constructed by the KC can 


be stored back into orem field of ab_req_info. The 
pci end_conj, beeen and endwasterisk: are 
integer fields which store the positions they describe in 
the request template, i.e., (unfin_ret). The conjunction is 
that portion of the request template which must be repeated 
as many times as necessary to hold the values returned 
from the previous inner-level request. The asterisks 
indicate where in that request the attribute-values nee be 
placed. The field req_len holds the value of the maximum 
size in bytes of the fully-formed ABDL request that the EC 
builds and sends to the KDS. The req_ien is cCaiculated by 
the KC and is) used for allocating storage for the fully- 
formed ABDL request which 1S constructed from the request 
template. 

The req_status is a flag used to indicate whether we 
are processing the first request or subsequent requests. 
Curr pes 1s an integer-valued variable that 15 used to 
indicate our current soci te in the current-request file 
and that marks which attribute-value is the next one to be 
inserted into the request being constructed. The res_len 
1s the last field in the record of type kce_rel_info and 1s 
an integer-valued variable which contains the lenath of the 
response Buffer returned by the MBDS. This value is used to 
indicate when we have completed our movement through the 
response buffer. 


The final field used by the KC in the sql_info record 


ve 


type 1s subreq_ stat. This integer-valued variable is a flag 
used when the .KC is handling a nested select. The flag 
1s set to indicate elther that the last subrequest is 


Being processed or an intermediate subrequest is being 


processed. 


B. KC PROCEDURES AND FUNCTIONS 


The KC makes use of a number of different procedures 


a 
a 


and functions to manage the transmission of the 


translated SQL queries (i.e.,ABDL requests) eo cme ©£O05. —Noc 
all of these procedures and functions will be discussed in 
detail. Instead, we hope to provide the a te 3 with an 
overview of how the KC controls the submission of the 
various types of ABDL transactions to MBDS. 

1. The Kernel _ Controller 


The procedure Kernel Controller is called whenever 


ome Lit has an ABDL transaction for the KC to process. 


This procedure provides the master control over all 
other procedures used in the EC. The first portion of 
this procedure initializes global pointers that are 
used throughout the EC. The other portion of the procedure 


15 a case statement which calls different procedures based 


upon the type of ABDE transaction that 1s being processed. 


If a new database 2S)6©6hbeing)=6 «Created, the procedure 
load_tables as called. If the transaction 15 a retrieve- 
common request, an insert request, a delete request or 


Teds 


ae 


an update request, the procedure rest request handler 


is called. If -the transaction is a retrieve 


request, then the procedure select _requests handler is 
called. If the transaction is none of the above, there 


iS anerror. An error message is generated and control is 
returned to the LIL. 
2. The Creation of a New Database 
The ‘ creation of ‘a new @atabase is the least 
difficult transaction that the KC handles. The procedure 


load tables 1s called by the KC and performs two functions. 


First, the test interface (TI) procedure dbl-template is 


— a 
—-e - 


called. This procedure is used to load the database- 
template file created by the FEMS. Next the TI procedure 
GbPeditr tbls is called. This procedure loads the 
database-descriptor file. These two files represent the 
attribute-based metadata that is loaded into the KDS, i.@on 
MBBS. After execution of these two procedures, load_tables 
returns control back to the kernel controller which in turn 
returns cContrel pack Eee@rne tale. 
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S. Insert, Delete, Update and Retrieve-Common Requests 

Insert, delete, update and retrieve-common requests 
are all handled in a similar fashion. For any of these four 
types of requests, the KMS sends the translated ABDL request 


to the FC for processing. The main task of the KC for these 


four categories of requests is to send the ABDL request to 


the EDS (MBDS) for processing. Ber laine = emia are ai Bb 
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of requests by calling the procedure rest_requests_handler 
which calls the procedure sql_execute. The procedure 


sqil_execute controls the submission of ABDL requests to the 


KDS. To control the submission process the procedure 
sql_execute uses two TI procedures and the Procedure 
sql_chk_responses_ left. In general, the procedure 


sql_execute sends the ABDL request to the KDS, waits for the 
last response to be returned from the KDS and then takes 
action appropriate for the type of request submitted and the 
response received. For any of the request types sent to the 


ee 


KDS an error response might be received back. In this 
Situation, i = message 1S sent to the user. Pian 
error response was not received, then the ABDL request was 
correctly Processed. Be ae) insert, delete and update 
requests, the user 1S: sent a Bac cace informing him that the 
Beer atin has Deen successfully executed. For a retrieve— 
common request, ene results returned by the KDS are sent to 
the KFS for formatting. Control then returns upward through 
the various procedures until it reaches the LIL. 
pees er Peyee Requests 

ABDL retrieve requests are the other category 
Of requests that the KC processes. The processing of 
retrieve requests is more complex than the other eS or 
requests, since multiple retrieves (which correspond to S@L 


nested-selects) may need to be processed. The procedure 


select requests handler is called to process ARBDL retrieve 
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requests. © | «nttie SQL select is being processed, then 
only ome ABDL retrieve is generated by the KMS. Lf an SQL 
nested-select is being processed, then two or more ARDL 
retrieve requests are generated by the EMS. Only the first 
ABDL retrieve for an SQL nested-select 1S a complete AERDL 
retrieve. The remaining ABDL retrieves are actually ABDL 
request templates. An ABDL request template and the results 
of the previous retrieve are combined by the KC to build the 
fully-formed ABDL request. The procedure 
select _requests_ handler manages both possible situations. 
First, the procedure sql_execute is called to process the 
initial ruiliereeaea ABRDL retrieve request. If this request 
2S not an SCL nested-select, no other ABDL request templates 
.remain. If ABDL request templates are left to process, then 
a loop is entered to process these retrieves. This loop 15 
repeatedly executed until all ABDL request templates Nave 
been a a 

An overview of the activities concen by sethas 
locp 18S necessary to understand how the EC handles the S@L 
nested-select. One of the initial steps in the loop is a 
Cali to the procedure swap_files. This procedure obtains 
the results generated by the previous ABDL request (which 
are stored in the future-results file by the procedure 
file_future_results) and puts them into the current-results 
file, where they are used to build the next ABDL retrieve. 


The number of values in the current-results file (‘which has 


1%) 


been determined when the values are loaded into the file) is 
obtained for use in the Procedure. After some 
initialization steps are executed an inner loop is 
encountered. This inner loop controls the actual building 
and executing of the current ABDL request template which 
corresponds to one of the outer-level SOL selects. 

The inner loop calls the procedure build request to 
produce the next fully-formed ABDL retrieve. Control in 
this procedure is branched based upon.which of the eleven 
possible S@L operators is in the current request. These 


eleven possible S@L operators result in four possible 


Situations. For the operators <=ANY, <ANY, *s=ALL and =ALL 
the procedure one_conjunction is called with the maximum 
Value of the -results in the current results file passed as a 
parameter. (The maximum and minimum values were calculated 
by the ee eet: Aes ite when the values were 
loaded into the ee nee file.) For the operators 
SSANY, ANY, “<=A4LL and <ALL the procedure one_conjunction is 
also called. this time with the minimum value of the results 
in the current-results file passed as a parameter. For the 


IN and “~“=ANY operators the procedure n_conjunction 158 


eat ied. eal = a the NOT IN operator the procedure 
rmet_in_conjunction 1s called. These three conjunction 
procedures all produce one or more fully-formed AEBDL 


retrieves using the request template. The inner loop then 


calls sql_execute to process the ABDL retrieve. The inner 


Bt 


loop concludes with some steps that prepare for the next 
retrieve. The inner loop repeats as long as there are vane 
left in the current-results file and the procedure 
One_conjunction has .not been called. The outer fee then 
sets up for the next ABDL retrieve and concludes. A more 
detailed example of how the procedures n_conjunction, 
not_in_conjunction, and one_conjunction work will be covered 


in the following two sections. 5 


» 


a. The N_ conjunction Procedure 

The procedure n_conjunction uses the ABDL 
request template and the values from the previous ABDL 
retrieve stored in the current-results file to build a 
fully-formed ABDL retrieve. The ABDL request template 
contains a portion of the AHBDL request which we have labeled 
the conjunction. This conjunction portion of the request 
eerste is bounded a the first set ot outermost 
parenthesis ee those requests handlied by the procedure 
nN CON J UBeGEVene This conjunction contains a number od 
predicates that are "and’ed" together. A predicate is a 
tripie consisting of an attribute mame, followed by a 
relational operator (l.@.,5 5 23, 9 6..) fellowed #5), so8 
attribute value. Recall that in an earlier discussion we 
stated that the request ane contains an unspecified 
attribdute-value. In our current terminology, this means 


that a predicate in the conjunction of the request template 


has an unspecified:attribute-. value. To mark this value 


within the request template character string, we use a 


series of asterisks, where the number OT asterisks 
corresponds to the maximum attribute-value length. The 
Procedure n_conjunction uses the conjunction DGmtdeimn 


repeatedly with each conjunction having a different value 
from the results file inserted in place of the asterisks. 
The conjunctions are then "“or’ed" together to form the 
fully—-formed ABDL retrieve. * ; 
We have chosen not to allow an unlimited 


number Of conjunctions to be joined together into one ARBDL 


request. Rather we have created an upper limit on the 
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maximum number of man Sune nS that may be joined together 
into a single ARDL retrieve. We call this constant 
NUM_CONJ. Thus, assuming we have NUM_CONJ set to ten, 
only ten conjunctions can be linked together in one ABDL 
retrieve. This means only ten values from the current— 
results file can be loaded into the retrieve, one oper 
Cem Junction. If there are mere than ten results in the 
current-results file, then more than one ABDL retrieve 
must be built. This situation necessitates the inner 
leop discussed in the procedure select_requests_handler. 

We now look at an example, to fully understand 
the operation of the procedure n_conjunction. We will build 
the outer ABDL retrieve for the nested select presented 
presented in Chapter IV. The S@L nested select 1s as 


follows: 


SELECT name, age 
FROM student 
WHERE name IN 
( SELECT name 
FROM LacuLley ) 
This query would find the name and age of all students who 
are also a member of the faculty. The KMS maps the SQL 
nested-select to the following two ARDL retrieves. 
a 
a 
* C RETRIEVE (TEMPLATE = FACULTY) (NAME) J 


C RETRIEVE ((TEMPLATE = STUDENT) and 
(NAME = ¥¥##H EKER HEHE) ) (NAME, AGE) 1] 


The first ABDL retrieve which corresponds to the innermost 
SQL request is executed by the procedure sql_execute. The 
results of this retrieve will be names of personnel on the 
faculty are sterned 1m ERG (Cur mem Gage seed Wee 
that there are three names returned and that they are 
Demurjlan, Mack and Kloepping. 

The procedure n_ cCeonJjuneerenrm marks several 
locations in the request template the first time it is 
called for a particular S@L request. The procedure stores 
the location of the beginning and the end of the conjunction 
and the location of the first and last asterisk which 
delineates the unspecified attribute-value. In the previous 


example the conjunction is as follows: 


((TEMPLATE = STUDENT) and (NAME = %*% 4444444) ) 


This conjunction is to be used three times to construct the 
fully-formed ABDL retrieve. The ABDL retrieve tee by the 
procedure n_conjunction is shown in Figure 19. 

If there had been more than NUM_CONJ names in 
the current-results file, then more than one fully-formed 


a 


ABDL retrieve would have to be generated for the 
corresponding SOL select. The first NUM CONJ names would 
have to be inserted into Serentearos that are "or’ed" 
together. Another ‘ABDL retrieve would then Hilaire USING 
the next NUM_CONJ names from the current-results file. ABDL 
retrieves woOuld continue to be built until all names in the 


Current-results file have been exhausted. 


5. the Frocedures Not _in_conjunction and 
One_conjunction 


The procedure not_in_conjunction operates in a 
Similar fashion to the procedure n_conjunction. The major 
difference is that the conjunction portion of the request 
DEMURJIAN)) or 


MACE) ) or 
KeGe- Fr Thaw 


STUDENT) and (NAME 

(({TEMPLATE = STUDENT) and (NAME 

((TEMPLATE = STUDENT) and (NAME 
(NAME, AGE) J 


Beeeele VE ¢( (TEMPLATE 


pooure 19. The ABDL Retrieve Generated by the 
Procedure N_ conjunction. 


template is smaller and the conjunctions are "and’ ed" 
together rather than "“or’ed" together. Suppose Creke we 
replace the IN operator in the previous S@L nested-select 
query with the NOT IN operator. The-resulting S@L query 
would find the name and ages of all students who are not 
members of the faculty. The first ABDL retrieve would be 
identical to the first ABDL retrieve in the last example. 


The second ABDL retrieve would now be as follows: 


C RETRIEVE ((TEMPLATE = STUDENT) and 
(NAME VS #4 HHH) (NAME, AGE) J 


The conjunction portion for the procedure not_in_conjunction 


would be as follows: 

((TEMPLATE = STUDENT) and (NAME Y= «*««% HHH H*) ) 
The procedure not_in_conjunction inserts the names from the 
current-results file into this conjunction and "ands" the 


conjunctions together. The fully-formed ABDL retrieve is 


shown in Figure 2@. 
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C RETRIEVE ((TEMPLATE = STUDENT) and (NAME *= DEMURJIAN) 
and (NAME ~= MACK) and (NAME Y= KLOEPPING) ) 
(NAME, AGE) j] . 
Figure 28. The ABDL Retrieve Generated by the 
Procedure Not_in_conjunction. 

I¢ there are more than NUM_CONJ names in the current-results 

file, then, as before, additional ABDL retrieves would be 

generated. The multiple ABDL retrieves to be generated are 

handled identically as they are in the procedure 
nee@en junction. 

The procedure one_conjunction manages a simpler 


Situation. For the procedure one_conjunction:'we are also 


sent an SBDL ee ee by the KMS. In these tyre 
Situations all that must be done is to replace the asterisks 
with the minimum or maximum value that has been passed into 
the procedure as a parameter. Thus, the procedure 
one conjunction simply removes the asterisks and inserts tne 
passed in value in its place. It 185s only necessery for this 
singie ABDL retrieve to be cenerated once. For example, 


Suppose we are processing the following S@L nested-select. 


SELECT name, age 
FROM student 
WHERE age <AbL 
C SEEEBET age 
PROM faculty ) 


This S@L query will retrieve the names and ages of all 


students that have an age less than all the faculty ages. 
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In other words, this request finds the names and ages of all 
students who have an age less than that of the youngest 
faculty member. The KMS maps the SQL nested-select to the 


following two ABDL retrieves. 


C RETRIEVE (TEMPLATE = FACULTY) (AGE) J 


C RETRIEVE (¢(TEMPLATE = STUDENT) and 
(AGE <= #*#*+#)) (NAME, AGE) 1 


b) 
a 


te the first retrieve results in ae ages of 34, 43, i/7 
and 39 being returned. Since the SQL operator is «ALL, the 
minimum age is passed to the procedure SRS SG) uae Se The 
full y-formed ABDL retrieve that the procedure 


one_conjunction generates is shown in Figure 21. 


C RETRIEVE (TEMPLATE =" FHeELt y¥> (AGE) J 


C RETRIEVE ( (TEMPLATE = STUDENT) and 
(AGE <= #«*)) (NAME, AGE) J 


Pi geurewet., The ABRDL Retrieve Generated by the 
Procedure One_conjunction. 
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VI. THE KERNEL FORMATTING SYSTEM (KFS) 


The KFS is the fourth module in the SQL Ilanguace 
interface and is called from the kernel controller (KC) 
when the KC has obtained the final results from MBDS. 
The results are passed to the KFS in one or more character 
buffers, called response buffers. IfSthere is more than one 


response buffer, the KC calls ane KFS again for each 


buffer. The KFS manipulates the contents OF these 
buffer ¢s) to create an image of an S@L results table. fhis 
table is fermated ina file on each call to the EP Se 


Hence, this allews the user to view the results of his 
Queries as if he is working with an S@L-type database 
system. The following example illustrates this process: 
1. The user issues a query: 
SELECT NAME,AGE 


FRGMEMEeO YES 
WHERE AGE = 24 


=. The query is processed by all modules ot the 
interface. Fventually, the KFC receives the final re- 
sults. 

=. the KC calls the KFS for each response buffer. 


4. The KFS uses the response buffer to create the output 
table. For illustrative purposes, suppose that the 
response buffer contains the following data: 


NAME JOHN AGE 29 NAME STEVE AGE 26 


S. The EFS displays the appropriate S@L output table: 


ao 


‘ EMPLOYEE : 
‘NAME : AGE | ; 

t JOHN 1 99} 

leqisvis | heey et 

$= “- 


It 1s important for the reader to note that the table 
actually consists of two parts. The first part is the 
table heading and column headings. <In the example above 
this is the attribute called NAME followed by the 
attribute AGE. These are column headings. The table 
heading consists of the name of the relation, EMPLOYEE. The 
second part ic Geta of these attribute nmames or 
results, i1.e., attribute values. In our example, JOHN and 


STEVE are results pertaining to the attribute NAME; while 


=? and 26 are the results pertaining to the attribute AGE. 


A. THE EFS FrReegess 

In this section we discuss the processes that the EFS 
uses to create an S@L output table. We present these 
processes in the same sequence as they are performed by 
the  Eroe We begin this discussion, however, with an 
overview of those data structures unique to the EFS. This 
overview can facilitate our understanding of the C code that 


constitutes this module. 
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i. Overview of the KFS Data Structures 


The KFS utilizes, for the most part, just three of 
the structures defined in the VaneWise tatert sce The first 
of these, shown in Figure 22, is a record that contains 
information needed by the KFS to process the results. 
The first field in this record, response, contains the 
result from MBDS which is loaded by the KC just prior to 
calling the KFS. The second fiel@, curr_pos, telis the 


KFS where it is in the GeSsOnSe gai 2st? Seats | owe ia 


maintain a correct orientation in the response buffer. The 


next field, res_len, indicates the length of the 
response buffer. This value is)§6Lmostiy used as a 
Ralting condition. For instance, the KFS continues ES 


Sul li Characters out of the buffer while some index is iesess 
than or equal to the res_len. The next field, form_data, 15 
a record = and contains information about the outsut table 


heading. This record will be discussed in the following 


- 


Serudet KTS rel_into 


< 


char #response; 
ent Curr pos; 
PMc res_len; 
struct table _header_info form_data; 
struct fi le.inte Gsfile: 

int status; 
Struct rattr_node *first_rel; 
struct rattr_node *sec_ rel; 
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Figure 22. The kfs_rel_info Data Structure. 


A 


paragraph. The fifth field, o_file, is aiso a record. The 
o file record contains the file name and the file 


eee 


identifier of the file cae the KFS is building the 
Output table in. This is needed by the C language to open 
the Output file for read, write, or append access. The 
next field, status, acts as a flag. If this is the first 
time the KFS is entered for a particular set of response 
buffers and, therefore, a particular user, then this field 
contains a value of FIRSTIME. This tells the KFS that it 
needs to initialize values and set various structures for 
subsequent processing. The status is changed ‘after this 
is eee iB ape this initialization is not to be 
repeated for subsequent calls to the KFS for the same set 
of responses. The seventh field, first_rel, 1S a pointer 
to a list of attributes for the relation being currently 
processed. The data pertaining ta this list can be 
considered the schema of the current relation. The 
specific data that is needed from the schema is the 
maximum size ‘fin terms of the maximum attribute length) 
that the attribute named in this structure can possibly 


take on. This information is needed so that the correct 


column width for each attribute can be built into the output 


table. The final field is used for the same reasons 
discussed above, but is needed to implement the JOIN 
command. 


0 
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The second structure the KFS uses extensively is 
also a record ae is called table header_info and is 
depicted in Figure 23. The purpose of sie record is to 
provide information about the heading of the output table. 
Mee first field, tablecwidth, is an integer value 
containing the width of the espe olin table. This 
information tells us whether or not the table can fit 
within one ‘horizontal screen width. This serves as the 


basis for some of our logic in the KFS and is discussed in 


detail ain the next section. The next field, first_ent, 
points to another record that contains ainformation about 
the first Scene name ain the heading of the output 
table. The last field is the same = as the previous one 


except -that it points to the the current table_entry_info 
record that the KFS is now working with. 

The third data structure, like the previous two, 
1s)60 ho also 3 a =reccerd. This record Maintains all of the 
information needed to correctly position attribute names 


in the heading of the output table. It also contains 


Struct table _header_info 


e 
i 


int table _ width; 
Struct table _entry_info *first_ent; 
struct table_entry_info *ciipr ent; 


Be 
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Figure 23. The table _header_info Data Structure. 
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ene information needed to correctly position the results 
under eae appropriate headings. The first field, —" 
in Figure 24, 185 a character sap containing the name of 
an attribute that 1s used as part of the output table 


heading. The second field 1s an integer value containing 


the length of the stored attribute name. This value 15 
compared with the next field ta determine the actual 
width of the column ‘for this particular attribute. 


The next field, val_len, contains :an integer value that 
is the maximum -size a result of this attribute type can 
possibly take on. The fourth field, col_len, holds the 
maximum of the two previous fields and is the actual 
width of a column for a particular attribute in the output 
table. The last field, next, is just a pointer to the 
next record of this type. Using this field the KFS can 
move from one record to another record and create the 


correct heading until it hits a NULL record. 


Struct table_entry_info 


x i 
j 


char attrCANIength + 1] 
Lime name_len; 

ime Val_len; 

Pits col _len; 

struct table_entry_info next; 


a. 4 
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Figure 24. The table_entry_info Data Structure. 
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Zs KFS Procedures and Functions 


The KFS makes use of a number of procedures) and 


functions to create a é finished S@L results table from a 


response buffer. We do not discuss all of these iin 
detail. Rather, we dco provide an overview of the more 
salient ones. We hope the reader may gain a more rounded 


appreciation of our effort from this discussion. 
a. [Initializing 2 : 
ar Whenever the KFS is called, the initialization 
is required. This Precess Basically involves setting 
Values in the KFS data structures. For instance, the 
curr pos is _— ao the first character in the response 
bitrfer . The initialization procedure also opens the output 
file ain which the S@L table is to be created for the proper 
access. When the KFS is called for the first time, this 
file is opened for write access. Sib sceWeme calls to the 
KFS for the same set of queries open this file for append 
access. This is done so that we do not overwrite data 
already in this file. The appropriate actions taken by the 
Initialization routine 1s controlled by the value in the 
status. This value is updated by this routine after the 
fiese. Cail. 
b. Filling the Table Headings 

The first time that the KFS 1s called the 

response buffer is scanned so that information may be 


Gathered about the attribute names of the results. ais 


information is used by the KFS to create the header part of 
iam output table. 

This routine begins by reading the Purest 
attribute from the response buffer. The string length 
of this attribute is determined next; followed by a 
trace through the list of attributes in the schema of 
the current relation. The trace is completed when this 
attribute is found in the schema. Atethis point, the maximum 
Size that a value of this attribute type may take on can be 
determined. This information is stored in val_len. The 
maximum Of val_len and the string length of the attribute 
1S then calculated and placed in col_len. This value 


represents the actual column width this attribute will 


nave im the output table. The -unwary reader may miss the 
importance of this step. It iS easy to assume that the 
oniy value needed is val_len. However,. let’sS assume 


there 1s an attribute called ZIFP_CODE. The maximum number 
Of characters this attribute may have is five digits. laf 
we do not consider the string length of this) attribute 
name, then the column size would be just five characters 
wide and ZIP_CODE would appear as ZIF_C in the heading. 
This process of reading the next attribute is 
iterated until either it has cycled through a series of 
unique attribute names or it has processed all the 


attributes in the response buffer. 
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c. Creating the oe ae the Output File 
This part of the KFS Ss) 8S ee ee the 
workhorse of the module. The previous two BH GCae toe 
are instrumental in manipulating data structures and 
setting variable values so that this process may fulfill the 
intended mission of the KFS. Therefore, we discuss some 
of the issues we have struggled with while desiqning this 
part of the KFS. The two most important issues are: 
f. How should the table appear to the user? 
ie How should the table be stored internally, 1.e., 


Should it be ina file, a character array, or dis- 
played immediately to the user”? 


Dur oroblem has been that we have had no 
concrete examples of what an S@L table should look like. 
Should the headings be ‘centered within the columns, 
with the results centered under these headings? We 
didn‘t know. We Scie decided upon a convention that 
would facilitate seo gr acne Hence, we left-justified both 
the headings and the results with blanks added at the end oft 
each to insure proper spacing within the columns. As it 


turned out, this is also the way Date CRef. 17: pp. 117-142] 


presents his examples. 


The second issue has posed a problem. Gar 
aie st =] design has called for building the table in a 
character array. The only other aiternative considered at 


this time has been to immediately put the table on the 


screen as results are being passed to the FFS. This idea 
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is dismissed, however, when we Nave realized the 


difficulties: ofetmyingeto build aptabte omether rly. In a 


Similar fashion, - the idea of building the table ina 
character array 1s also dismissed. There is no way for 
us to predetermine the size Of this array. We have 


thought that 1t is unmeconomical to allocate a huge array 
to cover all possible table sizes. There 1s also the 
problem of moving around in the array. This : indexing 
prdablem created a preponderance of C code. 

Our only other alternative is to build the table 
im a file. _ This method has proved very easy to do. The 
operating ee maintains position within the file, “so, 
there 1S no indexing problem. In addition, there is more 
economical use of the computer’s resources, since the file 


is only as big as necessary. Hence, we have opted to build 


the table ina file. 


With these issues resolved, the 
implementation of this process has been straightforward. 
First, the headings are built in the output file. This 
1S done only the first time the KFS is called. Next, the 
attribute values are pulled from the response butfer and 
olaced left-justified under the corresponding 
attribute: Then, the process is jee csees aire LP tine 
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response buffer is exhausted. Subsequent osigee to the KFS 
for the same set of queries cause results to be aaa 
to the table in the file. 
d. Displaying the Table 

The KFS displays the S@L table to the user when 
Aaa response buffers | have been processed. This occurs 
when a special signal is detected im the last buffer in 
conjunction § with the setting of%a status signifying the 
last sub_request of a nested select.: An initial problem we 
have had with this process has been how to display a 
table more than twenty-four lines long: 7 A unique 
orocedure, patterned after the ‘more’ facility in UNIX 
CRet. 18], 1s developed. This function, when firse 
called, displays the first twenty-two lines of the SQL 
table and then prompts the user. The user can choose from 
a number of options... For ainstance, the user can have 
another screen-full of results displayed, or the user can 
display some number of lines less than twenty-two, or the 
user can even terminate the current menu of the lanquage 
imterface. Our intent is to make viewing the results as 
convenient as possible to the user. 

2. Cleaning Up 

Refore leaving the EFS, Ene. data.)  Struceurese 
used to create the SQL table ars freed. This ensures that 
the resources are available to process other queries. 


Additionally, the status field is updated to FIRSTIME. This 
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places the KFS in the correct state to process subsequent 


Queries correctly. 


B. A LIMITATION GE we tRS 

Although we have tried to make the KFS as general 
as possible with regard to creating and displaying S@L 
tables, there is one facility we have deliberately 


neglected to incorporate.  'RIS Ds Se ei ee re ern Seen 


a 
a 


2 
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tables with widths aruetes than eighty columns. Since 
Our intent is to only = show enae the interface could 
indeed be developed, we Nave decided that the programming 
effort required -to provide this facility is too Geely for 
the benefits derived. However, this 1s not to imply that 
this facility 1s not useful or needed. As a matter of 
fact, we have intentionally designed the FFS for the easy 


insertion of this code when it is developed. 
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Vit. CONCLUSION 


In this thesis, we have presented the specification 
and implementation of a S@L language interface. This is 
one of four language interfaces that the multi-lingual 
database system will support. In other words, the multi- 
lingual database system will be ableato execute transactions 
wrttten in four well-known and important data languages, 
namely, SQL, DL/I, Daplex, and CODASYL. S@L is of course 


the well-known relational data language provided by, for 


= 
- 
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xample, IBM SQL/Data System. In our case, we support SOL 

transactions with our language interface by way of LIL, EC, 
EMS, and KFS in place of S@QL/Data System. A related thesis 
by Benson and Wentz CRef. 19] examines. the specification 
Tene lementation~er the DL/I language ~inter+tace-. Two 
other theses on CODASYL and Daplex respectively are under 
way. This work foo Spat Set wchndes ag research being 
conducted at the Laboratory of Database Systems Research, 
Naval Postgraduate School, Monterey, California. 

The need to provide an alternative to the development 
of separate stand-alone database systems for specific data 
language models has been the motivation for this research. 
In this regard, we have first demonstrated the feasibility 


of a multi-lingual database system (MLDS) by showing how a 


1Q1 


Software SQL language interface can be constructed. 


Specific contributions of this thesis include | the 


development of useful algorithms and the implementation 
of S@L operations such as: nested retrieval, join 


operations, retrieval of grouped attributes, and updating 
multiple fields. In addition, we have developed a LIL ‘that 
is virtually reusable. With minor modifications the LIL can 
be used with the other language inte&faces. As a matter of 
fact, it has been recently modified for the DL/I language 
interface. Our design of the generic data structures: is 
also noteworthy. Because of our extensive utilization oft 
unions (2. fen, vaaene records), the other language 
imterfaces can use our generic data structures. We have 
extended the work of Macy (CRef. 2] and Rollins (CrRef. 3] by 
specifying and implementing the algorithms for the language 
interface. In addition, we have also provided a gqenerai 
organizational description = a MLDS. 

A major goal has been to design a S@L-to-MBDS interface 


without re@auiring any change be made to MEDS or ARBDL. Our 


implementation may be completely resident on a host 
Fomputer oar the controller. All S@L transactions are 
nerformed in the SQL interface. MBDS continues ae, 


receive and process transactions written in the unaltered 
syntax of ABDL. In addition, our implementation has not 


required any change to the syntax of SQ@L. The interface is 


tee 


completely transparent to the S@L user as well as to the 


MeDL . 

In retrospect, our level-by-level, top-down 
approach to the design of the interface has been a good 
choice. This implementation methodology has been the most 


familiar to us and proved to be relatively efficient in 
time. In addition, this approach permits follow-on 


programmers -to easily maintain and{modify (when necessary) 


the code. Subsequently, they will know exactly where we 
have stopped and where they should begin because we Rave 
included many. of the lower-level stubs. Hence, it 1S an 


easy task of Ue ieee) oe these stubs with code. 

We have shown that a S@QL interface can be implemented 
aS part oF a Pie) oe ie have provided a softwars 
structure to facilitate this Ynterface, and we have 
developed the actual code for implementation. The next 
step is to implement the other interfaces. When these 
are complete, the system needs to be tested as a whole to 
determine how efficient, effective, and responsive it is 
to users’ needs. The results may be the impetus for a new 


direction in database system research and development. 
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Tae purpose of this appendix is to present . pictorial 
of data structures used in the SQL language interface. 
Since the code used for the thesis was the C programming 
language, the diagram makes use of its constructs just 
as the code does. Groups of related items are known as 


structures in C, and it 1S easy to see from the diaqram 


that the structures break down intosmore detailed,: workable 


structures. There are two major parts of this appendix. In 
Figure 235 we present the relational database schema data 
structures that were discussed in Chapter 2. In Figure 


= 


=5 we present fae ee data structures. 

In the diagrams am arrow indicates that the field 
is a pointer to a structure. Each of the fields cf such 
a structure is preceded by a small arrow to indicate that 
indeed a pointer from another structure is referencing 
£ ess a ediele An example of this is the field si_dd1l_files 
e+ the S@QL_INFOQ structure in Fiqure 26 on page iis. The 
field si_dd1l_files points to a structure of type ODDL_INFO. 
This is especially useful when writing or tracing long paths 
through the user data structure. 


On the other hand, bracket lines are used to indicate 


when a field of a Structure is also a Structure. The 
DBracket lines are drawn from the "“parent" field to the 
“Ghiid” . stmuerune: A period is placed in front of the 
bracketed structure Ss fields Ee mpd iesceetht et oce. An 
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example of uiPhey Vel east erat sien) aesi=pNs) ego Asai) Se} ei ae, 
Structure in Figure 26 on page DEBT Ge The field Si «sq]_ tran 
is a structure of type TRAN_INFO. The bracket lines and the 


periods indicate this. 


We note that the diagram has a few instances of UNIONS. 


oe Und On 1s a construct that allows the user to connect 
different structure types, specified by the union 
Peaveture., to a Common structure,, i.e€-, unions. are also 


refered to as variant records. Sages Gene emiuil ta—linguat 
database system 1s to support the mapping of multiple 


lanquages, many portions of the user structure aoe Meee 


* = 


same for any language used. However, the union construct 
allows for the parts that must change between language 
interfaces so that the common data structures can be adapted 


to be useful to all of the language interfaces. 
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APPENDIX B - THE LIL PROGRAM SPECIFICATIONS | 


module SQL-INTERFACE 


db-list : list; /* list of existing relational schemas a 
head-db-list-ptr: ptr; /* ptr to head of the relational schema list */ 
current-ptr: ptr; /* ptr to the current db schema in the list */ 
follow-ptr: ptr; /* ptr to the previous db schema in the list */ 
db-id : string; /* string that identifies current db in use */ 


proc LANGUAGE-INTERFACE-LAYER(); 
/* This proc allows the user to interface with the system. */ 
--/* Input and output: user SQL requests oy 


stop: int; /* boolean flag */ 
answer: char; /* user answers to terminal prompts ~*/ 


perform SQL-INIT(); ~~ 

stop = false’; 

while (not stop) do 
/* allow user choice of several processing operations */ 
print ("Enter type of operation desired"); 
print (" (1) - load new database"); 
print (" (p) - process existing database"); 
print (" (x) - return to the to operating system"); 
read (answer); 


case (answer) of 
|)’: /* user desires to load a new database */ 
perform LOAD-NEW(); 

: /* user desires to process an existing database */ 

perform PROCESS-OLD(): 

x’: /* user desires to exit to the operating system */ 
/* database list must be saved back toa file */ 
store-free-db-list (head-db-list, db-list); 
stop = ‘true’; 
exit(); 

default: /* user did not select a valid choice from the menu ~*/ 
print ("Error - invalid operation selected"); 
print ("Please pick again")’ 
end-case: 


/* return to main menu */ 
end-while; 


end-proc; 
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proc SQL-INIT(); 


end-proc; 


proc LOAD-NEW(); 

/* This proc accomplishes the following: ee 

/* (1) determines if the new database name already exists. 7 
(2) adds a new header node to the list of schemas, ; 
(3) determines the user input mode (file/terminal), 
/* (4) reads the user input and forwards it to the parser, and */ 
(5) calls the routine that builds the template/descriptor files */ 


x / 
/ 


answer: int; /* user answer to terminal Sroants a 
“more-input: int; /* boolean flag */ 
proceed: int; /* boolean flag */ 

stop : int; /* boolean flag */ 

db-list-ptr: ptr; /* pointer to the current database */ 

req-str: str; | /* single create in SQL form */ 


ptr-abdl-list: ptr; /* ptr toa list of ABDL queries (nil for this proc)*/ 
tfid, dfid: ptr; /* pointers to the template and descriptor files */ 


/* prompt user for name of new database */ 
print ("Enter name of database"); 

readstr (db-id); 

db-list-ptr = head-db-list-ptr; 


stop = ‘false’: 
while (not stop) do 
/* determine if new database name already exists */ 
/* by traversing list of relational db schemas ~*/ 
if (db-list-ptr.db-id = existing db) then 
print ("Error - db name already exists"); 
print ("Please reenter db name"); 
readstr (db-id); 
db-list-ptr = head-db-list-ptr; 


end-if; 
else | 
if (db-list-ptr ~ 1 = ’nil’) then 
stop = ‘true’; 
else 


/* increment to next database */ 
db-list-ptr = db-list-ptr — 1; 
end-else; 


end-while; 
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/* continue - user input a valid ‘new’ database name */ 
/* add new header node to the list of schemas and fill-in db name */ 
/* append new header node to db-list */ " 


create-new-db(db-id); 


/* the KMS takes the SQL creates and builds a new list of relations */ 
/* for the new database. After all of the creates have been processed */ 
/* the template and descriptor files are constructed by traversing */ 
/* the new database definition (schema). a 


more-input = ‘true’; 
while (more-input) do 


/* determine user’s mode of input */- . 

print ("Enter mode of input desired"); 

print (" (f) - read in a group of creates from a file"); 
print ("  (t) - read in a single create from the terminal"); 
print (" (x) - return to the main menu"); 

read (answer); 


= 


case (answer) of © 
‘P: /* user input is from a file */ 
perform READ-TRANSACTION-FILE(); 
perform CREATES-TO-KMS(); 
perform FREE-REQUESTS(); 
perform BUILD-DDL-FILES(); 
perform KERNEL-CONTROLLER(); 


't’: /* user input is from the terminal */ 
perform READ-TERMINAL(); 
perform CREATES-TO-KMS(); 
perform FREE-REQUESTS(); 
perform BUILD-DDL-FILES(); 
perform KERNEL-CONTROLLER(); 

’x’: /* emit back to dell ~/ 
more-input = ‘false’; 

default: /* user did not select a valid choice from the menu */ 
print ("Error - invalid input mode selected"); 
print ("Please pick again"); 
end-case; | | 
end-while; 


end proc; 
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proc PROCESS-OLD(); 
/* This proc accomplishes the following: iar 
/* (1) determines if the database name already exists, ~*/ 
/* (2) determines the user input mode (file/terminal), */ 
/* (3) reads the user input and forwards it to the parser */ 


answe?r: int; /* user answer to terminal prompts */ 

found: int; /* boolean flag to determine if db name is found */ 
more-input: int: /* boolean flag to return user to LIL */ 

proceed: int; /* boolean flag to return user to mode menu ~*/ 
db-list-ptr: ptr; /* pointer to the current database */ 

req-str: str; /* single query in SQL form *, 


ptr-abdl-list: ptr; /* pointer to a list of queries insxABDL form */ 
tfid, dfid: ptr; /* pointers to the template and descriptor files */ 


- 


/* prompt user for name of existing database */ 
print ("Enter name of database"); 

readstr (db-id); | __ 

db-list-ptr = head-~db-list-ptr;. 


found = ‘false’; 
while (not found) do 
/* determine if database name does exist */ 
/* by traversing list of relational schemas */ 
if (db-id = existing db) then 
iouma = ‘true’: 
end-if; 
else 
db-list-ptr = db-list-ptr ~ 1; 
/* error condition causes end of list(’nil’) to be reached */ 
if (db-list-ptr = nil’) then 
print ("Error - db name does not exist"); 
print ("Please reenter valid db name"); 
readstr (db-id): 
db-list-ptr = head-db-list-ptr; 
end-if: 


end-else; 


end-while; 
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/* continue - user input a valid existing database name */ 
/* determine user’s mode of input */ 


more-input = true’; 
while (more-input) do 
print ("Enter mode of input desired"): 


print ("  (f) - read in a group of queries from a file"); 
print ("  (t) - read in a single query from the terminal"); 
print (" (x) - return to the previous menu"); 


read (answer); 


case (answer) of 

Pf: /* user input is from a file */ ° : 
perform READ-TRANSACTION-FILE();  * 
perform QUERIES-TO-KMS(): 
perform FREE-REQUESTS(); 


't’: /* user input is from the terminal */ 
perform READ-TERMINAL(); 
perform QUERIES-TO-KMS(); 
perform FREE-REQUESTS(); 


x’: /* user wishes to return to LIL menu */ 
more-input = ‘false’; 


default: /* user did not select a valid choice from the menu */ 
print ("Error - invalid input mode selected"); 
print ("Please pick again"); 
end-case; 


end-while; 


end-proc; 
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‘proc READ-TRANSACTION-FILE(); 

/* This routine opens a create/query file and reads the requests */ 
/* into the request list. If open file fails, loop until valid *,; 

/* file entered ne 


while (not open file) do 
print ("Filename does not exist"); 
print ("Please reenter a valid filename"); 
readstr ( file); 

end-while; 


READ-FILE(); 


af 


end-proc; 


proc READ-FILE(); 
/* This routine reads transactions from either a file or the */ 
/* terminal inta the user’s request list structure so that */ 


/* each request ‘may be sent to the KERNEL-MAPPING-SYSTEM. 


end-proc; 


proc READ-TERMINAL(); 
/* This routine substitutes the STDIN filename for the read */ 
/* command so that input may be intercepted from the terminal */ 


end-proc; 
proc CREA TES-TO-KMS(); 
/* This routine sends the request list of creates one by one */ 
/* to the KERNAL-MAPPING-SYSTEM ay 
while (more-creates) do 
KERNAL-MAPPING-SYSTEM(); 


end-while; 


end-proc; 
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*/ 


af 


proc QUERIES-TO-KMS(); 
/* This routine causes the queries to be listed to the screen. */ 
/* The selection menu is then displayed allowing any of the */ 
/* queries to be executed. si 


perform LIST-QUERIES(): 
proceed = ’true’; 
while (proceed) do 
print ("Pick the number or letter of the action desired"); 


print (" (num) - execute one of the preceding queries"); 
print (" (d) - redisplay the file of queries"); 

print (" (x). - return to the previous menu"); 

read (answer); «. “ . 


case (answer) of 
‘num’: /* execute one of the queries */ 
traverse query list to correct query; 
perform KERNAL-MAPPING-SYSTEM(); 
perform KERNEL-CONTROLLER(); 


‘d’ : /* redisplay queries */ 
perform LIST-QUERIES(); 


: /* exit to mode menu */ 
proceed = ’false’; 


default : /* user did not select a valid choice from the menu */ 
print (" Error - invalid option selected"); 
print (" Please pick again"); 
end-case; 
end-while; 


end-proc; 


end-module; 
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APPENDIX C - THE KMS PROGRAM SPECIFICATIONS 


module KMS () 


perform parser() 


end-module KMS 


proc yyparse() .. : : 


se 
a 


70} 


This proc accomplishes the following : ve 

/* (1) parses the SQL input requests and maps them to appropriate */ 
i abd! requests, using LEX and YACC to build proc yyparse(). */ 
/* (2) builds the relational schema, when loading a new database. */ 


/* (3) checks for validity of relation and attribute names within */. 


i the giveri db schema, when processing requests against an */ 

ye existing database. - 

list: tgt-list /* list of attribute names */ 

list: templates /* relation name(s) */ 

list: insert-list /* list of values for insertion op */ 

string: temporary-str /* used for accumulation of query conjuncts */ 
string: abdl-str /* used for accumulation of abd] request */ 

string: join-str /* used for accumulation of join request */ 

boolean: nested /* signals a nested SELECT query */ 

boolean: creating /* signals a DbLoad - versus a DbQuery */ 
boolean: or-where /* signals an OR term in the WHERE clause */ 
boolean: and-where /* signals an AND term in the WHERE clause */ 
boolean: set-member /* signals set membership op, vice nested SEL */ 
boolean: common-attr /* signals COMMON attr predicate of JOIN op */ 
boolean: rell /* signals curr predicate assoc’d w/1st join rel */ 
boolean: rel2 /* signals curr predicate assoc’d w/2nd join rel * 
boolean: or-abdl-join /* OR in 1st join retrieve request */ 

boolean: or-kms-join /* OR in 2nd join retrieve request */ 

boolean: delete-all /* signals deletion of all records in relation *,/ 


int: target-list-length 
int: insert-list-length 
int: no-templates 
int: no-attributes 
int: attr-len 

char: attr-type 

char: db[! 

char: template|| 
char: attribute|| 


129 


% start statement 
% token /* LIST ALL TOKENS FROM "LEX". and their TYPE, HERE */ 


707 
Statement: query 


{ 

nested = FALSE 

free all tgt/insert lists and temp-str (malloc’d vars) 
return 


} 


| dml-statement 
x 


{ 

cat End-Of-Request ("|") to end of abdl-str 
free all tgt/insert lists and temp-str (malloc’dvars) 
return 


} 


| ddl-statement 
return 


} 


° 
? 


dml-statement: insertion 
| deletion 
| update 
} 
query: query-expr 


query-expr: query-block 


cat End-Of-Request ("|") to end of abdl-str 
} 


y 


130 


query-block: select-clause FROM from-list 
{ 
for (ea attribute name in tgt-list) 
Hen join) 
if NOT valid-attribute(db, template, attribute, attr-len) 
print ("Error - field name ’attribute-name’ does not exist") 
perform yyerror() 
return 
end-if 
end-if 
else 
a join exists -- check that tgt-rel(s) match at least 
one.from-list relation 


if (match ers) . 
“x print ("Error - attr’ attr not in from-list relations") 
perform yyerror() 
return 
end-if 
end-else 
end-for ~ 
cat "(" to abdl-str 
if (join) 
cat "(" to join-str 
end-if 


if (nested) 
fill temporary-str w/’*’s marking the length of the tgt attr 
end-if 


} 
A 


cat ")" to abdl-str 
if (! join) 
cat "(tgt-list’)" to abdl-str 
end-if 
else 
cat "(tgt-list’)" to abdl/join-str, as appropriate 
construct the rest of the abd] join request 
(ie, cat COMMON -str to abdl-str; cat join-str to Ayal str) 
end-else 


} 
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A: empty 
cat "FILE = ’relation-name” to aval-str 
} 

| WHERE boolean 


{ 

if (! join) && (or-where) 
cat ")" to abdl-str 

- end-if 

else if (or-abdl-join) 
cat ")" to abdl-str 

end-elseif 

elseif (or-kms-join) , i 
cat ")" to join-str 

~end-elseif 


} 


’ 


B: empty ; 
| GROUP BY field-spec-list 


cat "BY ’attribute-name’ to abdl-str 


} 


select-clause: SELECT 


if (nested) 
allocate another set of tgt/insert lists, temporary-str, 
and abd! strings 

end-if 

copy "| RETRIEVE " to beginning of abdl-str 


} 
G 


b] 


C: sel-expr-list 
| MULTOP 
{ 


/* retrieval of "all" attribute values desired */ 
if (MULTOP value /= ’*’) 
print ("Error - asterisk(*) operator expected") 
perform yyerror() 
return 
end-if 
} 


1 
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sel-expr-list: sel-expr 


copy first attribute name to tgt-list 


} 
' sel-expr-list COMMA sel-expr 


{ 


copy successive attribute name(s) to tgt-list 


} 


, 
sel-expr: expr 
, 


insertion: INSERT INTO . M 


= 


bd 


copy "| INSERT (" to beginning of abdl-str 
receiver COLON insert-spec 


eat) to abdl-str 
} 


, 
receiver: table-name 


cat "<FILE, ’relation-name’>" to abd]-str 


} 
D 


} 
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D: empty 

{ 

/* inserting info for "all" attribute values */ 

copy all attribute names from schema to tgt-list 

if (target-list-length < 1) 
print ("Error - rel does not exist, or has no attr’s") 
perform yyerror() 
return 


end-if 


} 
, LPAR field-name-list RPAR 
{ 
for (ea attribute name in tgt-list) 
if NOT valid-attribute(db, template, attribute,attr-len) 
print ("Error - field name ’attribute-name’ does not exist) 
perform yyerror() 
return 
end-if 
end-for 
} : 


; 


field-name-list: field-name 
{ 
target-list-length++ 
copy first attribute name to tgt-list 


| field-name-list COMMA field-name 
{ ; 
target-list-length++ 
copy successive attribute name(s) to tgt-list 


} 


insert-spec: literal 


if (length of tgt-list <> length of insert-list) 
print ("Error - not enough or too many values inserted") 
perform yyerror() 
return 
end-if 
for (ea attribute in tgt-list / ea value in insert-list) 
perform type-checking of attrribute-value pairs 
cat ",<’attribute-name’, ’insert-value’>" to abdl-str 
end-for 


} 


b] 


134 


# 


deletion: DELETE table-name 


{ | 
copy "| DELETE ( " to abdl-str 


i 


copy ‘table-name’ to templates 


} 
E 


{ 
if (delete-all) 
cat "TEMPLATE = ’table-name” to abdl-str 
end-if 
cat ")" to abdl-str_ 


} 


b] 
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E: empty 
delete-all = TRUE 


} 
| WHERE boolean 


if (or-where) 
cat "}" to abdl-str 
end-if 


} 


update: UPDATE table-name 


copy "| UPDATE ( " to beginning of abdl-str 
copy relation-name to templates 


} 


set-clause-list F 


cat "} ’set-clause-list’"” to abdl-str 


} 


° 
’ 


F: empty 
| WHERE boolean 


if (or-where) 
cat ")" to abdl-str 
end-if 


} 


} 


135 


set-clause-list: set-clause 


set-clause: SET fleld-name EQ expr 


if NOT validattribute(db, template, attribute, attr-len) 
print ("Error - field name ’attribute-name’ does not exist") 
perform yyerror() 
return 

end-if 

else 
copy '<’field-name = expr’>" to abdl-str 

end-else 


, ; SY 
} « 
, 
ddl-statement: create-table 


create-table: CREATE 


creating = TRUE 


locate db-id schema header 


} 
TABLE table-name COLON 
{ 


no-templates ++ 
create new template block 
enter ’relation-name’ in template block 


} 
field-defn-list 


’ 


field-defn-list: field-defn 
{ 


no-attributes ++ 


| field-defn-list COMMA field-defn 
{ 


no-attributes ++ 


} 
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field-defn: field-name LPAR type G RPAR 
{ 


create new attribute block 
enter ’attribute-name’ in attribute block 


} 


‘ 
’ 


G: empty 


{ 


set key-flag to ’0’ in attribute block 


1 COMMA NONULL 


set key-flag to ’1’ in attribute block 
=) 


type: CHAR LPAR INTEGER RPAR 
{ 


enter attribute type and‘length in attribute block 


} 
INT LPAR INTEGER RPAR 
{ 


enter attribute type and length in attribute block 


FLOAT LPAR INTEGER RPAR 
{ , 


enter attribute type and length in attribute block 


} 


’ 
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boolean: boolean-term 


if {! join) 
cat "-(FILE = ’relation-name’) and" to abdl-str 
cat temporary-str to abdl-str 

end-if 


} 
| boolean OR 


or-where = TRUE 
if {! join) 
abdl-str/11] = ’(’ 
cat ") or ((FILE = ’relation-name’) and" to abd)-str 
copy empty-str to temporary-str : 
~  end-if 


boolean-term 


if {! join) 
cat temporary-str to.abdl-str 
end-if 
else 
if (current predicate assoc’d w/same rel as previous predicate) 
abd] /join-strj/11] = ’(’ 
cat ") or ((FILE = ’rel-name’) and" to abdl/join-str {as approp) 
cat temporary-str to appropriate str (abdl/join-str) 
end-if | 
else 
abd] /join-str(as approp)[11 + 3] = ’(’ 
cat "and" to appropriate str {abd] /join-str) 
cat temporary-str to appropriate str (abdl/join-str) 
end-else 
copy empty str to temporary-str 
or-where = FALSE 
end-else 


} 


1 
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boolean-term: boolean-factor 
{ | 
if (join) && (! or-where) 
determine rel that curr predicate is assoc’d with 
if (rel1) && (! common-attr) 
cat "(FILE = ’rel-namel’) and" to abdl-str 
cat temporary-str to abdl-str 
cat " FILE = ’rel-name2” to join-str 
end-if 
if (rel2) && (! common-attr) 
cat "(FILE = ’rel-name2’) and" to join-str 
cat temporary-str to join-str 
cat." FILE = ’rel-namel’” to abdl-str 
end-if : 
if (common-attr) 
cat " FILE = ’rel-namel/2" to abdl/join-str’s 
end-if 
end-if 


| paaleantten: AND: 


{ 
and-where = TRUE; 
jie Jorn 
cat "and" to temporary-str 


end-if 


boolean-factor 
{ 
if (join) && (! or-where) && (! common-attr) 
if (rell) 
abdl-str/11 + 3) = ’(’ 
cat ") and" to abdl-str 
cat temporary-str to abdl-str 
end-if 
if (rel2) 
join-str{11 + 3] =’(’ 
cat ") and" to join-str 
cat temporary-str to join-str 
end-if | 
copy empty-str to temporary-str 
and-where = FALSE 
end-if 


3 
boolean-factor: boolean-primary 


1 
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boolean-primary: predicate 


3 
predicate: expr 


if (! join) 
if NOT valid-attribute(db, template, attribute, attr-len) 
print ("Error - field name ’attribute-name’ does not exist") 
perform yyerror() 
return 
end-if 
if (! and-where) 
allocate new temporary-str 
end-if 
cat "(’attribute-name’ " to temporary-str 
and-where = FALSE 
end-if 
else 
save ’type’ for later comparison during type-checking, 
in case this'ts the COMMON attribute predicate 
end-else 


} 


comparison 
if (nested) 
save attr name in case nest is actually a set membership op 


end-if 
} 


table-spec 
{ 
if (! join) 
cat ")" to temporary-str 
end-if 
else 
if (common-attr) 
save values of ’expr’, comparison’, & ’table-spec’ 
for the COMMON expr, and type-check the two attr’s 
end-if 
if (! and-where) && (! or-where) 
allocate initial temporary-str 
copy "(" to temporary-str 
end-if 
else 
cat "(" to temporary-str 
end-else 
cat '’expr’ ‘comparison’ ’table-spec’)" to temporary-str 
end-else 


} 


7 


é 6 
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comparison: comp-op 


if (! join) 
cat ’comp-op’ to temporary-str 
if (nested) 
copy type-op-code to abdl-str.rel-op 
end-if 
end-if 
} 


3 


comp-op: EQ 
PM J 


{ 
if (nested) 

cat J’ to ’M’ and save 
end-if 


} 
[ae 


> 
ee 


nested = TRUE 
} 


J: empty 
| K 


{ 
nested = TRUE 
} 


K: ANY | ALL 


3 


L: IN | NOT IN 


3 


M: NE {| RWEDGE ; GE | LWEDGE | LE 


») 
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table-spec: literal 
{ 
if (! set-member) 
if (literal/0])’ = QUOTE) 
strip quotes from literal 
change literal to ALPHANUMFIRST 
literal-const = FALSE 
end-if 
cat result, or original literal, to temporary-str 
if (nested) 
set first-ptr to top of abdl-str list 
end-if 
end-if | 
else . 
ve set-member = FALSE 
end-else 


} 


| query-expr 


increment ptr to next tgt/insert list, temp-str, and abdl-str 


} 
| LPAR query-expr RPAR 


{ 


increment ptr to next tgt/insert list, temp-str, and abdl-str 


} 


| expr 


{ 


common-attr = TRUE 


} 


3 
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literal: lit-tuple 
| LPAR entry-list RPAR 


set-member = TRUE 


case (set-membership-op) 


Sears lO: i <=ANY-< ANY >=ALL, > ALL */ 
cat ‘max of value set’ to temporary-str 

4,6,7,9 : /* >=ANY, >ANY, <=ALL, <ALL */ 
cat ’min of value set’ to temporary-str 

se jo NOTIN” *) 


cat first value to temporary-str 
while (other values exist) 
cat") and (’attr-name’ /= ’value’™ to temporary-str 
end-while | : 
O22: jain /=AN Y= / 
cat first value to temporary-str 
if {more values exist) 
abdl-str[11] = ’(’ 
or-where = TRUE 
end-if- ’ 


while (other values exist) 


cat ")) or ((TEMPLATE = ’rel-name’) and (’attr-name’" 


to temporary-str 
if ( rel-op = IN ) 
cat " = " to temporary-str 
end-if 
else 
cat " /= " to temporary-str 
end-else 
cat value to temporary-str 
end-while 
end-case 


1 


lit-tuple: entry 
LWEDGE entry-list RWEDGE 


3 
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4 


entry-list: entry 
{ 
/* copy first value to insert-list */ 
insert-list-length++ 
if ("entry(0|’ = QUOTE) 


strip quotes from entry 


change entry to ALPHANUMFIRST 


end-if 


copy result, or original entry, to insert-list 


; entry-list COMMA entry 
{ 


/* copy. successive value(s) to insert-list ae 


insert-list-length++- 
if (entry|0]’ = QUOTE) 
strip quotes from entry 


change entry to ALPHANUMFIRST 


end-if 


copy result, or original entry, to insert-list 


; 
entry: constant 


? 


expr: arith-term 
| expr ADDOP arith-term 


’ 


arith-term: arith-factor 


| arith-term MULT-OP arith-factor 


’ 


arith-factor: H primary 


3 


H: empty 
ADDOP 


b] 


primary: field-spec 
_ set-fn LPAR field-name RPAR 
| LPAR expr RPAR 


| constant 


? 


field-spec-list: field-spec 


? 
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a 


field-spec: field-name 
| ‘table-ename DOT field-name 


if (! valid-attribute(db, rel, attr, attr-len) 
print ("Error - ’rel.attr’ is invalid combination") 
perform yyerror() 
return 

end-if 

if (join) 
if (! or-where) || ( (or-where) && (! and-where) } 

if (table-name = rel1) 


rell = TRUE 
rel2 = FALSE | 

end-if ‘ 

if (table-name = rel2) 
rell = FALSE 
rel2 = TRUE 

end-if 

end-if 
end-if ~. 


} 
set-in: AVG | MAX | MIN | SUM | COUNT 


J 


from-list: table-name 


{ 


copy first relation name to templates 
if (tgt-list = null) 

fill tgt-list with "all" attribute names in the relation 
end-if 


| from-list COMMA table-name 
{ 


copy second relation name to templates 
join = TRUE 
allocate join-str 


} 


empty: : 
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constant: QUOTE 1] OUOi#E 


{ 
literal-const = TRUE 


perform type-checking 


} 
| INTEGER 
{ 


perform type-checking 


I: IDENTIFIER 
| VALUE 


3 


~~ 


field-name: IDENTIFIER : 


t 


a¢ 


#4 


table-name: IDENTIFIER 
{ Seg 
if (! creating) 
if NOT valid-table(db, template) 
print ("Error - relation name ’table-name’ does not exist") 
perform yyerror() 
return - 
end-if 
end-if 
} 


>| 
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end-proc yyparse 


proc parser () 


if (! creating) 
allocate and initialize first fgt/insert lists, temporary-str, and abdl-str 


/* if an old abdl-str exists, free it first */ 
end-if 


perform yyparse() 
reset all boolean and counter variables 


} 


end-proc parser 
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proc yyerror (s) 

char *s 

{ 

if (creating) 
set CreateDB-error-flag 
print ("Error msg - tell user which CREATE TABLE request was in error") 
free current schema (malloc’d vars) 

end-if 

else 
free all tgt/insert lists, temp-str, and abdl-strs 

end-else 

reset all boolean and counter variables 

} 


end-proc yyerror 


a@ 


~- 
a 
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# 


APPENDIX D - THE KC PROGRAM SPECIFICATIONS 


module Kernel-Controller() 


/* This procedure accomplishes the following: ei 

/* (1) Initialization pointers global to the Kernel Controller. af 

/* (2) Checks si-operation to determine whether we are creating a a 
ie database, retrieving information from the database, deleting  */ 
ip information from the database, inserting information into the */ 
i database, updating the database or if there are errors. a 

/* (3) Depending on the appropriate operation the corresponding oa 
a procedure is called. . ear) 


begin module 
sql-ptr = &(cuser-rel-ptr-> ui-li-type.li-sql); 
ke-ptr = &(sql-ptr->si-kc-data.kci-r-kc); 


/* Initializes pointers global to the kernel controller */ 


/* look at the si-operation to determine what action to take */ 
case sl-operation 


’Create a database’: 


perform load-tables(); 
break; 


"Execute retrieve requests’: 


perform select-requests-handler(); 


break; 
*Execute retrieve common requests’: 
"Execute delete requests’: 
’Execute insert requests’: 


"Execute update requests’: 


perform rest-requests-handler(); 


break; 
‘Otherwise’: /* There are errors */ 


print error message; 


break; 
end case 


end module 
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44 


proc load-tables() 


/* This procedure accomplishes the following: a 
/* (1) Calls dbl-template() which is a procedure “a 
i already defined in the Test Interface. It loads */ 
/* the template file. a 


/* (2) Calls dbl-dir-tbls() which is another procedure ~*/ 
ie already defined in the Test Interface. It loads */ 
is the descriptor file. i 


begin proc 
do initialization; /* Initialize pointer */ 
4 


perform dbl-template(&template, ptr-> ddli-temp.fi-fid): 


~ 


perform dbl-dir-tbls(ptr- >ddli-desc.fi-fid); 


end proc 


proc rest-requests-handler() 
/* This procedure handles common retrieve requests, insert */ 


/* requests, delete requests and update requests by calling */ 
/* sql-execute(). a, 


begin proc 


perform sql-execute(); 


end proc 
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proc select-requests-handler() 


/~ ainis procedure accomplishes the following: iw 


/* (1) Determines if we have a series of requests which af 

ju corresponds to a nested select in SQL. sd 

/* (2) If we do have a series of requests we process the first */ 

ie request because this is the only fully formed ABDL a 

es request. This is accomplished by calling sql-execute(). */ 

/* (3) If it is a nested select, we enter a loop to process the */ 

i remaining requests. Note that it may be necessary to ~*/ 

a process sub-requests. This requires entering another */ 

ie loop to process these. This occurs when the number of */ 

si responses to a request is larger than NUM-CONJ. In this | 
- situation a-request contains at most NUM-CQNJ values. */ 

/* .(4) If it is not a nested select, then only one request se 

/*- requires processing. This is accomplished by calling */ 

ve sql-execute. a 

begin proc 


curr-req = &(sqkptr>si-abdl-tran-> ti-curr-req); 

/* Set curr-req equal to the first request to be processed */ 
num-reqs = &(sql-ptr->si-abdl-tran->ti-no-req); 

/* Set num-reqs equal to the number of requests to be processed */ 
ke-ptr->kcri-file-status = FIRST TIME; 

/* Set the file status to indicate it is the first time through */ 
kc-ptr->kcri-req-status = FIRSTT IME; 

/* Set the request status to indicate it is the first time through */ 
Kce-ptr->kcri-num-values-ffile = 0; 

/* Set the number of values in the file to zero */ 
strcpy (kc-ptr->kcri-files.nri-futr.fi-fname, CURRF Name); 

/* Assigns filename for the current file */ 
strcpy (ke-ptr->kcri-files.nri-curr.fi-fname, FUTRF Name); 

/* Assigns filename for the future file */ 


*num-reqs = *num-regqs - 1; /* Decrement num-regqs */ 

if (*num-reqs == 0) /* Its the last subrequest */ 
sql-ptr->si-subreq-stat = LASTSUBREQ; 

else /* Its an intermediate subrequests ~/ 


sql-ptr->si-subreq-stat = INTERSUBREQ; 


perform sql-execute({); /~ Handles the first request */ 
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while (*num-reqs > 0) /* It is a nested select */ 

begin while 
*num-reqs = *num-regs - 1; /* Decrement num-reqs */ 
perform swap-files(); /*~ Swap current and future files */ 
ke-ptr->kcri-num-values-cfile = kc-ptr->kcri-num- values-ffile; 

/* Set the number of values in the current file *’ 
kc-ptr->kcri-num-values-ffile = 0; 

/* Reinitializes the number of values in the future file */ 
ke-ptr->kcri-file-status = FIRSTTIME; /* Reintialize the status */ 
sql-ptr- >si-subreq-stat = INTERSUBREQ; /* Reinitialization the status*/ 
curr-req->rl-ab-req = curr-req->ri-ab-req- > ari-next-req; 

/* Advance pointer so it points to the next request */ 
kc-ptr->kcri-unfin-ret = curr-req->ri-ab-req- > ari-req; 

/* Loads abd] request template into unfin-ret */ 

curr-req->ri-ab-req->ari-req = NULL; 

/* Sets ari-req to empty so that the completed request can */ 

/* be built into ari-req */ 
kc-ptr->kcri-req-status = FIRSTTIME; /* Reinitialize request status */ 
one-conj-flag = FALSE; : 

/* Sets flag :to imdicate it is not a one conjunction type req */ 


while ((ke-ptr->kcri-num-values-cfile > 0) && ( !one-conj-flag }) 
/* There are values left to insert into the request */ 
begin while 
perform build-request( &one-con}-flag ); 
/* Builds the next request */ 
perform sql-execute(); 
/* Handles the request just built */ 
perform free{ curr-req- >ri-ab-req-> ari-req ); 
/* Frees ari-req */ 
curr-req->ri-ab-req- >ari-req = NULL; 
/* Reinitializes ari-req */ 
end while 


/* Sets up for the next request */ 

curr-req- >ri-ab-req- >ari-req = kc-ptr->kcri-unfin-ret; 
/* Set ari-req equal to unfin-ret; */ 

ke-ptr->keri-unfin-ret = NULL; 
/* Reinitailize unfin-ret ~/ 

perform fclose(kc-ptr->kcri-files.nri-curr.fi-fid): 
/*~ Close the current file */ 

end while 
end proc 


fa 


proc sql-execu te() 


/* This procedure accomplishes the following: | ca 

/* (1) Sends the request to MBDS using TI-S$TrafUnit() taf 
me which is defined in the Test Interface. “) 

/* (2) Calls sql-requests-left() to ensure that all requests */ 

ie have been processed. 7 

/* (3) Calls Tl-finish() for post operation processing. a 


begin proc 
perform TI-S$TrafU nit(sql-ptr->si-curr-db.cdi-dbname, 
‘ sql-ptr->si-abd]-tran-> ti-curr-req.ri-ab-req- > ari-req); 


/* Sends the request to MBDS si q 


perform sql-chk-responses-left(); 
/* Wait until all responses have been returned */ 


perform T]-finish(); 
/* Routine to tidy:things up after processing is completed */ 


end proc 
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proc sql-chk-responses-left() 


/* This procedure accomplishes the following: mi 

/* (1) Receives the message from MBDS by calling ai 
if TI-RSMessage() which is defined in the Test Int. aa 
/* (2) Gets the message type by calling TI-RSType. a 
/* (3) If not all responses to the request have been y 

ia returned, a loop is entered. Within this loop a ae 

ia case statement separates the responses received by ~*/ 
es message type. = 


/* (4) If the response contained no errors, then procedure */ 
ee T1-RSReq-res() is called to receive the response from */ 
ie MBDS. - | Pe 

/* (5) A check is then made to determine if this is the last */ 
/*. response. If it is, then the results are returned to */ 


a the calling routine. If it was not the last respon’se */ 
fe then the results are filed in future-results-file. */ 
/* (6) If the message contained an error then procedure oe 


/* TI-R$ErrorMessage is called to get the error message */ 
/* and then procedure TJ-ErrRes-output is called to ey) 
ye output the error mesage. a 
begin proc 
num-reqs = &(sql-ptr->si-abdl-tran-> ti-no-req); 
/* Number of requests left, not counting the request */ 


/* currently being worked on. */ 


response = sql-ptr->si-kfs-data.kfsi-rel.kri-response; 
/* Initailize response */ 


done = FALSE; /* Initialize flag */ 


while ( not done ) 
/* Not all responses for the current request have been received */ 


perform Tl-RSMessage(); /* Receive message from MBDS */ 


msg-type = TI-R$Type(); /* Get the type of the received message * / 
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case msg-type /* Is the response correct or are there errors? */ 


’CH-ReqRes’: /* The response is correct */ 
done = chk-if-last-response(); 
/* Set flag if its the last response */ 


case sql-ptr- >si-operation 


"Execute Retrieve Requests’: 
"Execute Retrieve Common Requests’: 
if (*num-reqs == 0) 
/* If there are no requests left, send the results to */ 
/* the formatter. */ 
Kfs(); | : 
- else 
a /*There are requests left the in nested select to process */ 
file-future-results(); /* Save the results */ 
break; | 


"Execute Delete Requésts’: 


print "Delete Query Done"; 
break; 


"Execute Insert Requests’: 
print "Insert Query Done": 
break; 


"Execute Update Requests’: 
print "Modify Query Done"; 
break; 


end case 


break; 


*Requests With Errors’: 
perform TI-RSErrorMessage(request ,err-msg); 
/* Get the error message */ 
perform TI-ErrRes-output(request,err-msg); 
/* Output the error message */ 
done = TRUE; /* Set the flag */ 
break; 


end case 
end while 
end proc 


154 


proc build-request( one-con)-flag ) 


/* This procedure accomplishes the following: os 

/* (1) Builds the next ABDL request to be processed by sa 
a calling either N-Conjunction, Not-In-Conjunction or */ 
a One-conjunction depending on the relational operator. */ 
/* (2) Sets one-conj-flag if procedure One-Conjunction is */ 
a called. tay 


begin proc 


curr-abdl-req = &(sql-ptr->si-abd]-tran-> ti-curr-req); 
/* Gets the current ABDL request . */ 3 


case curr-abdl-req-> ri-ab-req- > ari-rel-op 
/* Switches based upon the relational operator in the request */ 


"In Operator’: 
perform Cea ieee: 


break: ” 


"Not In Operator’: 
perform Not-In-Conjunction(); 


break; 


‘Not Equal to Any Operator’: 
perform N:Conjunction(); 
break; 


"Less than or Equal to Any Operator’: 
perform One-Conjunction(kce-ptr->kcri-max.maxi-val.dvi-int); 


*“one-conj-flag = TRUE; 
break; 


‘Greater than of Equal to Any Operator’: 
perform One-Conjunction(ke-ptr->kcri-min.mini-val.dvi-int); 
*one-conj-flag = TRUE; 
break; 


"Less than Any Operator’: 
‘perform One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int); 


*“one-conj-flag = TRUE; 
break; 
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’Greater than Any Operator’: 
perform One-Conjunction(kc-ptr->kcri-min.mini-val.dvi-int); 
*one-conj-flag = TRUE; 
break; 


"Less than or Equal to Al] Operator’: 
perform One-Conjunction(kc-ptr->kcri-min.mini-val.dvi-int); 
*one-conj-flag = TRUE; 
break; 


‘Greater than or Equal to All Operator’: 
perform One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int); 
*one-conj-flag = TRUE; : 
break; 

"Less than All Operator’: 
perfrom One-Conjunction(kce-ptr->kcri-min.mini-val.dvi-int); 
*one-conj-flag = TRUE; 
break; 


7. 


‘Greater than All Operator’: 
perform One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int); 
*“one-conj-flag = TRUE; 
break; 


end case 
end proc 
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proc N-Conjunction() 


We 
rhs 
ia 
i 
/* 
/ ios 
/* 
/* 
Vie 
/* 


This procedure accomplishes the following: a 
(1) Builds an N conjunction ABDL request using a template 


(the unfinished return) provided by KMS. oh 


(2) This is accomplished by loading in the action portion of */ 


the template, loading up to NUM-CONJ conjunctions into 
the request, ’oring’ the conjunctions together and then */ 


followed by the remainder of the conjunction. If this */ 
is not the last conjunction of the request, then an or */ 
is inserted and the next conjunction is constructed using ey 
the same process. z/ 


begin proc 


- 


abdl-ptr = sql-ptr-> si-abdl-tran->ti-curr-req.ri-ab-req; 
/* Set pointer to the current ABDL request */ 


if (ke-ptr->kcri-req-status == FIRSTTIME) 
/* Calculates values that will be used on all calls to this procedure */ 
/* for a given request. Thus, these values are only calculated once. */ 


begin if 


for (i = 0: ke-ptr->kcri-unfin-ret/i) != LPARAN; i+-) 


BL) 


Oi 


ay 


adding the target list. a) 

(3) The conjunction portion is formed by copying from the */ | 
beginning of the conjunction to first asterik of the ay, 
template into ari request. Then the next value from the */ 
the current file is inserted into the ari request, i 


kc-ptr->kcri-beg-con} = 1;/*Mark position where the conjunction begins* / 
action-len = kc-ptr->kcri-beg-conj;/*does not include Ist LPARAN */ 
for ( ; kc-ptr->kcri-unfin-ret/i] != ASTERIK; i++) 


b] 
kce-ptr->kcri-beg-asterik = i;/*Mark position of the first asterik*/ 


fa 


/* Calculates the size of the template. */ 
unfin-ret-len = strlen(kc-ptr->kcri-unfin-ret); 


for (i = unfin-ret-len; ke-ptr->keri-unfin-ret{i] != ASTERIK; i--) 


} 
ke-ptr->kcri-end-asterik = i;/*Mark position of last asterik * / 
for ( ; kc-ptr->kcri-unfin-ret!i) != LPARAN; i++) 


? 


for ( ; ke-ptr->kcri-unfin-ret[i] != RPARAN: i--) 


7 
ke-ptr->kcri-end-con] = 1; 
/*Mark position of the end of the conjunction*/ 
target-len = unfin-ret-len - kc-ptr->kcri-end-con] + 1; 
conj-len = unfin-ret-len - target-len - action-len; 


a 
a 


. /* Calculates the maximum length of the finished request. */ 
- ke-ptr->kcri-req-len = (action-len + (NUM-CONJ * conj-len) + 
(NUM-CONJ * ORLen) + target-len); 
ke-ptr->keri-files.nri-curr.fi-fid = 
fopen(kc-ptr->kcri-files.nri-curr.fi-fname, "r''); 
ke-ptr->kcri-req-status = RESTTIME; 


end if 
else 
begin else 
/* Reset the length of the unfinished request */ 
unfin-ret-len = strlen(kc-ptr->kcri-unfin-ret); 
end else 


/* Allocates space for the finished. request. */ 
abdl-ptr->ari-req = var-str-alloc(kc-ptr->kcri-req-len); 


/* load request with action portion and an ( */ 
for (i = 0; 1 != (ke-ptr->kcri-beg-con] + 1); i++) 
abdl-ptr->ari-req|i] = kc-ptr->kcri-unfin-ret/i); 

I= 


158 


# 


counter = 1; 
while ((counter <= NUM-CONJ) && (kc-ptr->kcri-num-values-cfile != 0)) 
/*Keep building conjunctions, filling them with values 

& ’oring’ them together*/ 


begin while 
/* loads template up to asterik */ 
for (1 = ke-ptr->kcri-beg-conj; i != kc-ptr->kcri-beg-asterik; i++) 


begin for 
abdl-ptr->ari-req|j; = kc-ptr->kcri-unfin-ret/i]; 
is 
end for 
% 
/* loads in the next value */ - 


a for (i = 0; ((abdl-ptr->ari-req|j] = : 
getc(kc-ptr->kcri-files.nri-curr.fi-fid)) != ’0); i++) 
ie 


/* loads the appropriate number of ) behind the conj */ 
for (i = (kc-ptr->kcri-end-asterik + 1); 
i != (ke-ptr->kcri-end-conj + 1); i++) 
begin for 
abd]-ptr->ari-req|j) = kc-ptr->kcri-unfin-ret/i]; 
leet 
end for 


if ((counter != NUM-CONJ) && (kc-ptr->kcri-num-values-cfile != 1)) 
/* It is not the last conjunction */ 


begin if 
/* loads " or " into the request to connect the conjs */ 
abdl-ptr->ari-req/j++] = BLANKSPACE; 
abdl-ptr->ari-req|j++] = ’o’; 
abdl-ptr->ari-req|j++] = ’r’; 
abdl-ptr->ari-req|j ++] = BLANKSPACE; 

end if | 
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else /* It is the last conjunction */ 
begin else 
/* loads the target list one value oer line */ 
for (i = (ke-ptr->kcri-end-conj); 1 != (unfin-ret-len + 1); i+) 


begin for 
abdl-ptr->ari-req|j] = kc-ptr->kcri-unfin-ret/t!; 
Tirta 
end for 
/* checks if there is only one value in this request. | 
/* if true then one set of parenthesis is replaced with blanks */ 
if (counter == 1) » 
begin if . | : 


abdl-ptr- >ari-req|kc-ptr-> kcri-beg-conj = BLANKSPA CE; 
abdl-ptr- > ari-req|kc-ptr-> kcri-end-conj| = BLANKSPACE; 
end if 


end else 


counter++; 
kc-ptr->keri-num-values-cfile--; 


end while 
if (kc-ptr- >kcri-num-values-cfile == 0) 
/* Set the status to signify the last subrequest */ 


sql-ptr->si-subreq-stat = LASTSUBREQ; 


end proc 
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proc Not-In-Conjunction() 


/* This procedure accomplishes the following: oi) 
/* (1) Builds a one conjunction ABDL request using a template 7 / 
fe provided by KMS. + 


/* (2) This is accomplished by loading in the action portion of */ 
es the template, loading up to NUM-CONJ conjunctions into */ 


i the request, ’anding’ the conjunctions together and then */ 
a adding the target list. * / 

/* (3) The conjunction portion is formed by copying from the */ 
a beginning of the conjunction to first asterik of the sy 

ve template into ari request. Then the next value from the */ 
i the current file is inserted into the ari request - 


ie followed by the remainder of the conjunction. If this */ 
* is not the last conjunction of the request, then an and ~*/ 


Ve is inserted and the next conjunction is constructed a 
re using the same process. aa 
begin proc 


cd 
ad 


abdl-ptr = sql-ptr->si-abd]-tran->ti-curr-req.ri-ab-req; 
/* Set pointer to the current ABDL request */ 


if (kc-ptr->kcri-req-status == FIRSTTIME) 
/* Calculates values that will be used on all] calls to this for a */ 
/* given request. Thus, these values are only calculated once. */ 


begin if 
for (i = 0; kc-ptr->kcri-unfin-ret [i] != ASTERIK; i++) 


ke-ptr->kcri-beg-asterik = 1;/*Mark position of first asterik* / 
for ( ; kc-ptr->kcri-unfin-ret/i] != LPARAN; i--) 


b 
ke-ptr->kcri-beg-conj = i;/*Mark position where conjunction begins* / 


/* Calculates the size of the template */ 
unfin-ret-len = strlen(kce-ptr->kcri-unfin-ret); 
for (i = unfin-ret-len; kc-ptr->kcri-unfin-ret{i] != ASTERIK; i--) 


kce-ptr->kcri-end-asterik = i;/*Mark position of the last asterik* / 
for ( ; kce-ptr->kcri-unfin-ret/i] != RPARAN; i++) 
kc-ptr->kcri-end-con) = i; 

/* Mark position where the conjunction ends */ 
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action-len = kc-ptr->kcri-beg-conj; 
target-len = unfin-ret-len - kc-ptr->kcri-end-con); 
con)-len = unfin-ret-len - target-len - action-len; 


/* Calculates the maximum length of the finished request. */ 
kc-ptr->kcri-req-len = (action-len + (NUM-CONJ * conj-len) + 
(NUM-CONJ * ANDLen) + target-len); 
ke-ptr->kceri-files.nri-curr.fi-fid = 
fopen(kc-ptr->kcri-files.nri-curr.fi-fname, "r"); 
kc-ptr->kcri-req-status = RESTTIME; 
end if 
else 
begin else : q 
/* Reset the length of the unfinished request */ 
** unfin-ret-len = strlen(kc-ptr->kcri-unfin-ret); 2 
end else | 


/* Allocates space for the finished request */ 
abdl-ptr->ari-req = var-str-alloc(kc-ptr->kcri-req-len); 


/* load request with action portion and an ( */ 
for (1 = 0; 1 != (ke-ptr->kcri-beg-conj); i++) 

abdl-ptr->ari-req|i] = kc-ptr->kcri-unfin-ret/i]; 
Lae 


counter = 1; 

while ((counter <= NUM-CONJ) && (kc-ptr->kcri-num-values-cfile != 0)) 
/* Keeps building conjunctions, filling them with values and . */ 
/* ’anding’ them together. e/ 


begin while 
/* loads template up to asterik */ 
for (1 = kc-ptr->kcri-beg-conj; 1 != kc-ptr->kcri-beg-asterik; i++n) 
begin for 
abd]-ptr->ari-req|j| = kc-ptr->kcri-unfin-ret/|il; 
j++; 
end for 


162 


/* loads in next value */ 
for (i = 0; ((abdl-ptr-> ari-req|j] = 
getc(kc-ptr->kcri-files.nri-curr.fi-fid)) != ’0); i++) 
amas 


/* loads a ) behind the conjunction */ 
abd|-ptr->ari-req(j] = kc-ptr->kcri-unfin-ret/kc-ptr-> kcri-end-conj}; 
Vege 
if ((counter '= NUM-CONJ) && (kc-ptr->kcri-num-values-cfile != 1)) 
/* It is not the last conjunction */ 
begin if 
/* loads " and " into the request to connect the conjs */ 
abdl-ptr-> ari-req|j++] = er slams ila : 
* _ abd]-ptr-> ari-req|j++] = 
"abd ]-ptr->ari-req[j++] = a 
abdl-ptr->ari-req/j++] = ’d’; 
abd|-ptr->ari-req|j++] = BLANKSPACE; 
end if 


else /* It is the last conjunction */ 
begin else 
/* loads the target list including a */ 
for (i = (kc-ptr->kcri-end-conj + 1); i != (unfin-ret-len + 1); i++) 
begin for 
abdl-ptr->ari-req|j] = kc-ptr->kcri-unfin-ret/i]; 
j++; 
end for 
end else 
counter+-+; 
kc-ptr- > kcri-num-values-cfile--; 
end while 


if (kc-ptr->kcri-num-values-cfile == 0) 
/* Set the status to signify the last subrequest */ 
sql-ptr->si-subreq-stat = LASTSUBREQ; 


end proc 
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proc One-Conjunction (value) 


/* This procedure accomplishes the following: i 

/* (1) Builds a one conjunction ABDL request using a template */ 
i provided by KMS. a 

/* (2) This is accomplished by loading in the unfinished return */ 
- up to the first asterik, loading in the value passed to */ 

ye the procedure and then loading in the remainder of the */ 
yes of the unfinished return. ue 

begin proc \ 


abdl-ptr = sql-ptr->si-abd]-tran->ti-curr-req.ri-ab-req; 
/* Set pointer to the current ABDL request */ : 


for (i = 0; ke-ptr-> keri-unfin-ret(i} != ASTERIK; i++) 
kce-ptr->kcri-beg-asterik = i; /* Mark postion of the first asterik */ 


/* Calculate the.maximum length of the finished request. */ 
ke-ptr->kcri-req-len = (strlen(kc-ptr->kcri-unfin-ret) + INTSIZE); 
for (i = kc-ptr->kcri-req-len; kc-ptr->kcri-unfin-ret|i] != ASTERIK; i--) 


kc-ptr->kcri-end-asterik = 1; /* Mark the position of the last asterik. */ 
ke-ptr->kcri-files.nri-curr.fi-fid = 
fopen(kc-ptr-> kcri-files.nri-curr.fi-fname, "r'); 


/* Allocate space for the finished result. */ 
abdl-ptr->ari-req = var-str-alloc(kc-ptr->kcri-req-len); 


/* load request up to the first asterik */ 

for (i = 0; 1 != ke-ptr->kcri-beg-asterik; i++) 
abdl-ptr->ari-reqji) = kc-ptr-> kcri-unfin-ret/il; 

ee 


/* loads in the min or max value */ 
num-to-str (value, value-str); 
for (k = 0; k != strlen(value-str); k++) 
begin for 
abd]-ptr->ari-req|j] = value-str/k/; 
iia 


end for 
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/* loads the remainder of the request including the target list */ 
for (i = (ke-ptr->kcri-end-asterik ~+ 1); 
1 != strlen(kc-ptr->kcri-unfin-ret) +1; i++) 


begin for 
abd]-ptr->ari-req{j] = kce-ptr->kcri-unfin-ret/il; 
lei 
end for 
abdl-ptr->ari-req|j) =” ’: 
sqi-ptr->si-subreq-stat = LASTSUBREQ; 
end proc 
5 q 
proc chk-if-last-response() 
/* This procedure accomplishes the following: | 
/* (1) Determines the length of the response. we 
/* (2) Determines if this is the last response to a given request and */ 
/* returns a boolean indicating such. a 


begin proc 


/* Calculates response length */ 

for (response-length = 0; 
sql-ptr->si-kfs-data.kfsi-rel.kri-response response-length| != EOResult; 
response-length+-+); 
----response-length; 


/* Checks if this is the last response */ 
if (sql-ptr->si-kfs-data.kfsi-rel.kri-response|response-length - 3] 
== CSignal) 
return( TRUE); 


else /* It is not the last response */ 


return( FALSE); 


end proc 
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proc file-future-results() 


/* This procedure accomplishes the following: a 
/* (1) Removes the attribute names from the response. ~*/ 
/* (2) Places the remaining attribute values into the */ 


/* future-results-file. i 

/* (3) Keeps track of how many sub-requests there are. */ 
/* (4) Calculates and stores max and min values. say 
begin proc 


max-ptr = &(kc-ptr->kcri-max); /* Initialize pointer */ 
min-ptr = &(kce+ptr->kcri-min); /* Initialize pointer */ 
f-ptr = &(kc-ptr->kcri-files); /* Initialize pointer */ 


if (kc-ptr->kcri-file-status == FIRSTTIME) 


/* Do the following initialization */ 


begin if ae 
max-ptr-> maxi-val.dvi-int = MINVAL: 
min-ptr->mini-val.dvi-int = MAX VAL; 
f-ptr->nri-futr.fi-fid = fopen(f-ptr->nri-futr.fi-fname, "w"); 
kc-ptr->kcri-file-status = REST TIME; 

end if 


else 
f-ptr->nri-futr.fi-fid = fopen(f-ptr-> nri-futr.fi-fname, "a"); 


kce-ptr->kcri-curr-pos = 1; 
response = sql-ptr->si-kfs-data.kfsi-rel.kri-response; 


kc-ptr->kcri-res-len = strlen(response); 


/* Number of values in the returned result of the request */ 
num-values = &(kc-ptr->kcri-num-values-ffile); 
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while ( kc-ptr->kcri-curr-pos < (kc-ptr->kcri-res-len) - 2) 


begin while 
for (;response(kc-ptr-> kcri-curr-pos] != EMARK;kc-ptr-> kcri-curr-pos++) 
; /* Skip the attribute name */ 
(kc-ptr->kcri-curr-pos) ++; 
for (val-len = 0;response(kc-ptr->kcri-curr-pos + val-len| != EMARK; 
val-len ++) 
; /* Find out how long the attribute value is */ 


/* Allocate storage space for the value */ 
temp-str = var-str-alloc(val-len + 1); 
eS : 


-: for ( ;response{kc-ptr->kcri-curr-pos| != EMARK;kc-ptr-> kcri-curr-pos+-+) 


begin for 
/* Load the value into the future file */ 
putc(response|kc-ptr-> kcri-curr-pos|, f-ptr->nri-futr.fi-fid); 
/* Load the value into the temp string */ 
temp-str/j++) = response/kc-ptr->kcri-curr-pos|; 

end for 


(kc-ptr->kcri-curr-pos)++; 
putc(’0, f-ptr-> nri-futr.fi-fid); 


temp-strij) =’ ’: 
“num-values = *num-values + 1; /* Count the number of values */ 


/* Calculates the maximum value of those values returned so far */ 
max-ptr->maxi-val.dvi-int = 
max(max-ptr->maxi-val.dvi-int, str-to-num(temp-str) ); 


/* Calculates the minimum value of those values returned so far */ 
min-ptr->mini-val.dvi-int = 
min(min-ptr-> mini-val.dvi-int, str-to-num(temp-str)); 
free(temp-str); 
end while 


fclose(f-ptr->nri-futr.fi-fid); 


end proc 
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proc swap-files() 


/* This procedure swaps the contents of the future file with the */ 
/* contents of the current file. my 


begin proc 


curr-fp = &(kce-ptr->kcri-files.nri-curr); 
fut-fp = &(kc-ptr->kcri-files.nri-futr); 
temp.fi-fid = curr-fp- > fi-fid; 
strcpy(temp.fi-fname, curr-fp->fi-fname); 
curr-fp-> fi-fid = fut-fp- > fi-fid; 
strcpy(curr-fp- >fi-fname, fut-fp-> fi-fname); 
fut-fp->fi-fid = temp.fi-fid; 

strcpy (fut-fp-> fi-fname, temp.fi-fname); 
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end proc 
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APPENDIX E - THE KFS PROGRAM SPECIFICATIONS 


module kfs () 


/* This procedure accomplishes the following: oy 
/* (1) Calls initialize() = 

/* (2) Calls fill-table-headings() ) 

/* (3) Calls one-hscreen-results() if the width of the 7 
jaa output table is less than the width of the screen */ 
/* (4) Calls more() to output the results file if the last */ 


/* response buffer has been received = 
/* (5) Calls finish() to free used memory after the last */ 
/* .: response buffer has been received | 


begin module 
proc initialize(); /* Set up structures and variables for processing */ 
proc fill-table-headings(); /* Get headings for relational output */ 
if (table-width <= OutputCols) /* If table size <= screen width */ 
proc one-hscreen-resu|ts(); 
else 
proc all-hscreen-results(); /* This procedure has not been written */ 
if (last response buffer) 
begin 
proc more(); /* Output relational output file to screen */ 
proc finish(); /* Close out sturctures and variables and free space */ 
end if 
end module 
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proc initialize() 


a 
ia 
ha 
Vi 
7 
he 
i 
fe 


This procedure accomplishes the following: i! 

(1) Sets kfs-r-ptr to the address of the current relational ss 
database ma 

(2) Sets kri-curr-pos to 1, the starting point in the response */ 
buffer oe 


(3) If this is the first time for a particular set of responses */ 
then an Output File is opened for write status; otherwise */ 
the Output File is opened for append status ah 


begin proc 


: ‘ 9 
set, kfs-r-ptr to the address of the current relational database; 
kfs-r-ptr->kri-curr-pos = 1; /* Sets a pointer in the response array to 


the beginning of the array */ 


if (kfs-r-ptr->kri-status == FIRSTIME) /* If this is the first time 


that this procedure has been 
called for this particular 
response.....then..... 7 
begin 
open Output File for "write" status; 
kfs-r-ptr->kri-status = FIRSTBUF; /* Change status to indicate that 
the FIRST BUFFER is being 
handled */ 
end if 


else 


open Output File for "append" status; /* This is not the first time 
thru this procedure so we 
_ need to append the results 


to the results already in the 
Output File */ 


end proc 
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proc fill-table-headings() 


e 


/* This procedure accomplishes the following: | 
* / 


/* (1) Fills different fields in various structures so that an */ 
/* output table similiar to one created in SQL can be made ~*/ 
/* to show results coming from MBDS mh 


begin proc 
curr-pos = kfs-r-ptr->kri-curr-pos; /* curr-pos used to hold actual 
current position in the results 
buffer so that kri-curr-pos can 
be set back to this value when we 
exit this procedure */', 
allocate a new table-entry-info node; ' . 
read the attribute name from the response buffer; 
determine the length of this name and store in new-tei-ptr-> tel-name-len; 
new-tel-ptr->tei-val-len = proc get-size(new-tei-ptr->tei-attr); 
/* Get the max size that this attr can possibly take on */ 
new-tei-ptr->tei-col-len = proc max(new-tei-ptr->tei-name-len, 
ne new-tei-ptr->tei-val-len); 
/* Determine the actual column size in the output table */ 
thi-first-ent = new-tei-ptr; /* First entry for output table is equal 
to the results we just obtained */ 
thi-curr-ent = new-tei-ptr; /* The current entry is also equal to these 
a results */ 
proc skipnameorval(); /* Skip over the attr value in response buffer 
until the next attr name is hit */ 
temp-attr = next attr name in response buffer; 
while (temp-attr <> thi-first-ent->attr-name) 
begin 
allocate a new table-entry-info node; /*i.e., new-tei-ptr */ 
new-tel-ptr->tei-attr = temp-attr; 
determine the length of this name and store 

in new-tei-ptr-> tel-name-len; 
new-tei-ptr->tei-val-len = proc get-size(new-tei-ptr->tei-attr): 

/* Get the max size that this attr can possibly take on */ 
new-tei-ptr->tel-col-len = proc max(new-tei-ptr->tei-name-len, 

new-tel-ptr-> tei-val-len); 

/* Determine the actual column size in the output table */ 
tbl-ptr->thi-curr-ent->tei-next = new-tei-ptr; 
tbl-ptr->thi-curr-ent = new-tei-ptr; 
proc skipnameorval(); ~ 
temp-attr = next attr name in response buffer; 

end while 
kfs-r-ptr->kri-curr-pos = curr-pos; /* Restore current position * / 
end proc | 
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proc one-hscreen-results() 


/* This procedure outputs the results in SQL table form if this table */ 
/* can fit within the width of one screen : 7 


begin proc 
if (FIRSTBUF == TRUE) 
begin 
proc load-titles(); /* Output the headings of the table */ 
kfs-r-ptr->kri-status = RESTBUFS; /* Change status to indicate 
that titles/headings no 
longer have to be output */ 
end if 
while (kfs-r-ptr->kri-curr-pos < kfs-r-ptr->kri-res-lan) 
begin 
- tbl-ptr = kfs-r-ptr- >kri-form-data. thi-first-ent; 
/* Get the first table entry so that you can work from here */ 
while (tbl-ptr <> NULL) 
begin 
proc skipnameorval();- 
column-difference = tbl-ptr->tei-col-len - proc get-val-len(); 
/* column-difference indicates the difference between the 
actual column length and the length of the attr value to 
be output. We need this to determine how many spaces are 
needed to keep our results left-justified */ 
print the attr value; 
print a series of blank spaces equal to the column-difference; 


Diintea ae 
tbl-ptr = tbl-ptr->tei-next; /* Get the next table entry */ 
end while 
print a carriage return; 
end while 
close Output File; 
end proc 
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proc load-titles() . 


/* This procedure loads the heading of a SQL results table into the */ 
/* output file vag 


begin proc 
tbl-ptr = kfs-r-ptr-> kri-form-data.thi-first-ent; 
/* Get the first table entry so that you can work from here */ 
while (tbl-ptr <> NULL) 
begin 
column-difference = tbl-ptr->tei-col-len - tbl-ptr->tei-name-len; 
/* column-difference indicates the difference between the 
actuat column length and the length of the attr value to 
be output. We need this to determine how many spaces are 
needed to keep our results left-justified */ . 
print the attr name; , 
print a series of blank spaces equal to the column-difference; 
primt a "|": 
tbl-ptr = tbl-ptr->tei-next; 
end while 2 
print a carriage return: 
print a series of "-" equal to the width of the table; 
end proc 


proc get-size(x) 


/* This procedure obtains the maximum size that a particular attribute */ 
/* value may take on , 


char x; 
begin proc 
traverse the table entry list until you find the attr name equal to x; 


return(the length of this attr name); 
end proc 
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proc more() 


/* This procedure is just like the more facility offered in Unix */ 
/* It is not as sophisticated, however. 7 


begin proc 
open kfs-r-ptr->kri-o-file.fi-fname for "read" status; 
get a char from opened file; 
‘ while (NOT EOF) 
begin 
counter = 0; /* counter is used to keep track of how many lines 
have been printed on the screen */ 


while ((counter <= screen-heigth} AND (NOT EOF)) 


begin 
** print the char; ; 
if (c == carriage return) 


counter = counter + 1; 
get a char from opened file; 
end while 7 
if (counter > screen-heigth) 
begin 
print the word "--more--"; 
determine if user wants to quit or advance 1 to screen-heigth lines 
in the opened file; 
end if 
end while 
end proc 


proc skipnameorvail() 

/* This procedure skips over either an attribute name or attribute value */ 

/* depending where kri-curr-pos is currently located. This is necessary */ 

/* because results are coming back as) ATTR-NAME ATTR-VALUE. In some */ 
/* situations we want just the NAME and in others we want just the VALUE */ 


begin proc 


update kri-curr-pos to skip over the the attr name or value 
that it is currently positioned at; 


end proc 
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proc finish() 


* This procedure frees any structure space that may have been created * 
LDS p y Pp 
/* during the creation of the ouput table ¥/ 


begin proc 
tbl-ptr = current relational database; 
tbl-ent-ptr = tbl-ptr->thi-first-ent;/* Set tbl-ent-ptr to the first 
table entry /* 
while (tbl-ent-ptr <> NULL) 
begin : 
tbl-ptr->thi-first-ent = tbl-ent-ptr->tei-next; 
/* Get the next table entry */ . 
tbl-ent-ptr->tei-next = NULL; 
-: free(tabl-ent-ptr); 
tbl-ent-ptr = tbl-ptr-> thi-first-ent; 
end while 
end proc 
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A. Overview 

The SQL language interface allows the user to 
input transactions from either a file or the terminal. & 
transaction can take the form of either creates of a New 
database or Queries against an existing database. The 


SQL language interface is) menu-driven. When the 
: : . - 


i : : 
transactions are read from either a file or the terminal 


@ 


they are stored in the interface. If the transactions 


are creates they are executed automatically by the system. 


If the transactions are queries the user will be 
orompted by another menu to selectively pick an individual 


Query to be processed. The menus provide an easy = and 
efficient way ue allow the user to see and select the 
methods in which to perform the mapping functions. Each 
menu 1S. tied to its predecessor so that By exiting each 
menu the user is moved back up the menu "tree". This 


allows the user to perform multiple tasks in one session. 


B.. USING sige ower 

TRere are two operations the user can perform on 
the database schemas. The user can either create a new 
Gatabase or process queries against an existing database. 
The first menu displayed Prompts the user for which 
fUNcCEIOM COoMpertonn- This menu, hereafter named MENUI, 


looks like the following: 
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Enter type of operation desired 
(1) —- load a new database 
(Pp) — process old database 
(x) - return to the operating system 


See) ————- 


Upon selecting the desired operation, the user will 
be prompted to enter the name of the database to be used. 
For the case that the load operation was selected, the 
database name provided cannots a presently used. 
Likewise, for a process old operation the database name 
provided must be in existence. In either case, if an 


error occurs the user will be told to rekey a different 


a =. 


name. The session continues once a valid name has been 
entered. 

For either type of operation selected from MENUI1, the 
second menu is the same and asks for the mode of input. 
This input may come from a data file or interactively 
from “fhe terminal. The generic menu, called MENU2, looks 
like the following: 

Enter mode of input desired 

‘#) - read im a group of transactions from a file 


(tC) - read in transactions from the terminal 
(x) ~ return to the previous menu 


ACTION ----> 


I+ the user wishes to read transactions from a file he 
will be prompted to provide the name of the file that 


contains those transactions. If the user wishes to enter 


17a 


transactions directly from the terminal a message will be 


displayed reminding him of the correct format and 
special characters that must be used. Since the 
transaction list stores both creates and Queries, two 


different access methods must be employed to send the two 
types of transactions to the KMS. Therefore, our 
discussion branches to handle the two processes the user 
will encounter. : : - 
“1. Processing Creates 
When the user has specified the filename of creates 
(iF ene = tile 1s from a file) or typed in a set of creates 
(if the Ape pee the terminal), further user 
intervention 1S not required. It does not make sense to 
process only a single create out of a set of creates that 
produce a new database since they all must be processed at 
ence and in a specific order. Therefore, the 
transaction list of creates 1s automatically executed by 
the system. Since all the creates must be sent at once to 
form a new database, control should not return to MENU 
where further transactions can be input. Instead, 
COn etme: returns to MENU where the user can pick a new 
Operation or new database. 
In this case, after the user has specified his 


mode of Anoke. he will conduct an interactive session 


with the system. First, all queries will be listed to the 


17S 
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Screen. AS the queries are listed ‘from Ree sacticn 
lasts a anemia is assigned to each query in Ree 
order starting with the number = one. The number is 
Printed on the screen beside the first line of each query. 
Next, an access menu, called MENUS, is displayed which 


looks like the following: 


Pick the number or letter of the action desired 


(num) - execute one of the preceding queries 
(d) - redisplay the list of queries 
(x) - return to the previous menu 
Aneel ON SS==pee 
Since the displayed queries might exceed the 
vertical height of the screen, only a screen full of 
Queries will be displayed at one time. If the desired 


Query 1S not on the current page, the user can hit the 
‘RETURN key to display the next page of eres If the user 
only wishes to a" a certain number of lines, then after 
the first page is displayed the user can enter a number and 
only that many lines of queries will be displayed. [If the 
user 1S only looking for certain queries, once he hes 
Found them he does not have to page through the entire 
transaction list. By hitting the q_ key, control will 
preak from listing queries and MENUS will be displayed. 
Under nermal conditions when the end of the transaction list 


Ras been viewed, MENUS will appear. 
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Since queries are independent items, the order in 
which they are processed does not matter. The “ee has 
the choice of executing however many queries he desires. 
A loop causes the query listing and MENUS to be 
redisplayed after any query has been executed so that 
further choices may made. Unlike processing creates, 
control returns to MENU2 because the user may have more than 
one file of queries against a particular database or he 
may wish to input some extra queries - directly from the 
terminal. Once he has finished processing on this 
particular database, — he can exit back to MENUIi to either 


change operations or exit to the operating system. 


C. DATA FORMAT 

When reading transactions from a file or the terminal, 
there must be some way of distinguishing when one 
Cian a eeton ends and the mext begins. Transactions are 


allowed to span multiple lines as evidenced by a typical 


nested S@L select. Since the system i= reading the input 
line by linge, an end-of-transaction flag 15 needed. In 
our system this flag is the "@" character. Likewise, the 


system needs to know when the end of the input stream has 
been reached. In our system the end-of-file flaq is 
represented by the “#" character. The following is an 
example of an input stream with the necessary flags that 


must be included when multiple transactions are entered: 
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TRANSACTION #1 
@ 
TRANSACTION #2 
@ 


fa 


TRANSACTION #n 
+ 


D. RESULTS © q 


“when the results of the executed:transactions are 


sent 


back to the user’s screen, they will be displayed exactly 


the Same way queries are displayed (See section m2) 
The following consolidates the user’s options: 

nr eee 7 
ree FUNCTION 
+o ee 2 eee HH eH ee + 
» meturn displays next screenful of output 
: (mumber ) displays only (number) lines of output 
: Q stops output, MENU] is then redisplayed 
to ae eH HH He “ 


i81 


(4) 


(6) 


(7) 


(8) 


See) 


(14) 
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